World: r3wp

Only if the system is designed to support them. If not, then they 
are slower.

Erlang and stackless python which can create >100.000 "processes" 
surelly does not use uses native threads for this ... I imagine it 
has M(green processes) / N (OS processes)

(Erlang that is ... stackles py I think uses just green threads)

by system you mean the rebol runtime in our case or the OS?

The REBOL runtime.

aha, yes that I agree fully .. that's why I was hoping the makers 
would think about some form of lighter runtime threads/processes 
whatever they are :)

here is an example of how we could use the unit system if it where 
implemented.


ANY unit moniker could be used, and in fact the switch tables below, 
could be context-specific and dialect-configured, adding to the DSL 
power of  REBOL... 


ex: dm could be decimeter or deutchmark (the later should be DM anyways, 
no?) , based on context, the convertion units could mean either or... 
with a default convertion table explicitely defined.

a simple func could let us append or change the conversion tables 
used throughout the system.  


Imagine if the VID would use units directly.  you set your locale 
(or get it from OS) and see values as they should be for your locality.


unit-convert: func [
	in "unit value to convert"
	to-moniker "to what unit type to you want to convert to"
][
	; note: incompatible types set 'IN to value none
	in/value: switch to-moniker any [
		switch in/moniker [
			{mm} [
				[
					{m} [in / 1000]
					{dm} [in / 100]
					{cm} [ in / 10]
					{'} [in * 0.0032808399]
					{"} [in  * 0.0393700787]
				]
			]
			{"} [
				[
					{m} [ in * 0.0254]
				]
			]
		]
		; empty result set, switch on nothing
		[]
	]
	in/moniker: to-moniker
]


unit-convert 100mm "m"
== 0.1m

unit-convert 100" "m"
== 2.54m

unit-convert 2mm  {'}
== 0.0787401575'

Change /moniker to /unit.

just a label...  now find the more powerfull idea I added here  not 
readily obvious... but you should get it....  ;-)

It still wouldn't replace money!, because the international standard 
syntax for specifying money uses a prefix, not a suffix.

notice the inch handling ?

;-)

it would, if instead of switch functions we'll use parse

it's the same idea, of having computed/values (with accessors)

But Carl don't like the idea

no steeve, at that level, its the rebol lexical analyser.

we can't just but-in parser rules.  its a core level of the interpreter.

you can just use load/next in a parser rule... I've done it often 
and it works.

it has nothing to do with the lexical analyser, we just need a new 
data type, to construct computed variables

internally, those variables would be sort of objects with methods

but I would like a way to get invalid tokens loaded as invalid values... 
that way I'd use block parsing .  so far, I've been using string 
parsing about 90% of the time.  its a shame, since I'm loading stuff 
much more slowly than rebol could let me do it using its native loading.

but behaving like regular variables

we are talking about representing the lexical form of unit-like values 
here steeve, not the custom datatypes.

all OOP with accessors do exactly what you want.

i'ts the same thing, you just need a specific method (ie. dispalyed-as) 
for the computed vars

yes i can do it with OOP, but i don't want to have to code stupid 
things like my-var/set, my-var/get

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 :)