World: r3wp

But Carl don't like the idea

 - as I recall, changes in object semantics have been put off until 
 later, not permanently.

 those variables would be sort of objects with methods

  that is exactly WHAT an accessor-enabled variable IS  , also known 
  as a datatype   ;-)

the accessors are just events... you have to know WHEN and WHAT to 
do with a variable...   It would be fun if generic objects allowed 
us to set accessors per instance, just like python allows it, but 
alas, Carl doesn't realise just how often this could be used to simply 
a vast array of code.

simply = simplify

(repeating myself) As I recall, changes in object semantics have 
been put off until later, not permanently.

i don't ask a new semantic for objects (with obvious drawbacks)
i ask for a new datatype, let the objects like they are

All bound words are object fields or function context fields, so 
that is exactly what you are asking for.

yep so do it now :-)

put off until later, not permanently

Petr < has anyone problem, if money! datatype would be renamed to 
unit!>

Agreed ---- It seems likely that if money! had not existed in R2, 
none of us would be expecting R3's BCD datatye to be called money!

Given that so much of R3 is a break from R2, Let's make the small 
change [deliberate currency pun] and give it a better name.
We could keep money as a subtype of that.

Since objects are the basis of all datatypes where words can be bound, 
we are focusing on the design of those other datatypes first so we 
get a better idea of the requirements for objects. Other datatypes 
like modules and tasks, for example.

as-is!
(which mean nothing or all)

?

I was answering to Sunanda, a new name to replace money!

exact!

Maxim's suggestion might work syntactically, but we would lose the 
money! syntax, which is the ISO standard syntax for currency. If 
we added a unit! type with Maxim's syntax we could use the same implementation 
internally for both money! and unit!.

They would just differ in syntax.

However, remember that there are limits to the number of possible 
distinct units loaded at once. The value doesn't have more than 1 
byte available to refer to a unit, which means 255 possible units 
in use when you subtract the unspecified unit.

Carl had a blog about this related to money! ...

well, in some time, the dollar wil disappear, so we'll got one more 
unit free

I'm just using money! and unit! as placeholder names for the two 
datatypes though. Final names should be decided. The money! name 
is a good one for the current money! syntax because the syntax matches 
the international currency syntax standard.

The $ is part of the ISO standard, as is the limit of 3 alphabetic 
characters preceeding it.

quoting brian " the syntax matches the international currency syntax 
standard" well... to me that's resoved then .... lets call it currency! 
  :-)

money! means the same thing and is shorter :)

I've just looked up the terms in the dictionnary ... and money actually 
encompasses currency, so it actually is the more precise term here... 
 funny, I had the two words inversed in my head.

funny no one noticed the big lexical change proposed in my example 
unit-conversion example  ... or no one spotted it   ;-)

I just translated the function to a more efficient method in my head. 
What is the lexical change you mention, aside from the unit syntax?

I meant to say:  "no one argued about the .... "

note how inches are represented lexically... ;-)

Oh, the unit syntax. There would be limits to what you could do, 
but the principle is sound. You probably wouldn't be able to do 1".

hehe actually we could, but I understand that it woul make the lexical 
analyser that much more complex than it is already with the "" vs 
{} handling inside/outside of each other... adding the " to word 
would really make it complex. so I don't expect or specifically "want" 
it, just was wondering if some of you would react to it  ;-)

The lexical analyzer has syntax priorities - some characters are 
delimiters, " being one of those.

You need first-class functions to have continuations.

But, if you want them to have reasonable speed... some native support 
helps...

If you want continuations supported well you need to build on a continuation-passing-style 
runtime. As far as I know, the only practical one with good performance 
is Parrot.

That is, unless you switch to a compiled language.

brian, you seem to really know what's happening at various languages 
scene.. cool .. I was just looking a talk (video) about parrot VM 
where it presented these things few weeks back where a woman was 
presenting these features (and I consider myself a language nutcase 
;) )

I haven't really followed Parrot for a couple years - lost interest. 
Suppose I should take another look.

I'm not sure what model Stackless Python uses - in theory if could 
use CPS, but I haven't checked yet.

Strangely enough, the intermediate codes of many compiled dynamic 
languages are switching to SSE, which is procedural CPS.

CPS is cont. passing system... what is SSE ? :)

Static Single Assignment.

CPS = Continuation-Passing Style.

aha.. like in functional languages?

Sorry, SSA

The functional language equivaalent is CPS. SSA is for languages 
with assignment and/or modification.

sorry, my lack of proper CS education shows here :)

Well, the equivalency of SSA and CPS had not yet been demonstrated 
when I had my CS education (years ago).

Stackless moved away from CPS towards coroutines. I think Gambit-Scheme 
(even without compiling) does a decent job. 


I don't want to go the CPS route, but I find it intriguing that the 
Elephant in the room of re-entrant data blocks is .... an ELEPHANT. 
The fact that a problem is hard is no reason not to solve it.

It's not that it's hard, it's *why* it's hard. And that why is why 
R2 was so much faster than R1. Making the system resumable slows 
it down by orders of magnitude unless you design the semantics of 
the language around it.