World: r3wp

interesting, didn't know for words-of .. could a function somehow 
reference itself .. 
>> myfunc1: func [ b /local a ] [ words-of :myfunc1 ] myfunc1 123
== [b /local a]

(maybe I am wondering in stupid directions without much use here)

It looks like you have to know the function, since STACK/func doesn't 
seem to work for > 0 right now.

Unit! would be a great type, but it opens a lot of questions. If 
you treat it like money! works in R2, where the denomination is basically 
a tag, you get a lot of expressive power, and defer behavior to the 
user. 


The big thing is the notation, no? A serialized format seems to ugly 
to me, but I don't know how hard other options might be. Assuming 
no spaces, what looks natural?

100`kg
100/kg
100/m/s
100·m
100·m/s

I guess stack/func isn't used internally yet.

I don't think - or / will work very well with the lexer. Perhaps 
~ ?

Brian,  parse uses tables (at least last time I checked on compiler 
construction ;-) so it shoud be a easy to do.


If I have at/deep or so, I can creat a new head and build a stack 
of traversed parse rules. Actually that would represent the table. 
Which means I could do this today. And I can wite at/deep by using 
some recursion.

Thanks!

PARSE uses recursion - it's not a compiler generator.

Does REBOL use a shift-reduce parser?

hmmm, i have a security violation with A55 when using stack/args

Gregg, no.

I didn't think so.

Steeve, you have to start R3 with security turned off - use -s.

Gregg, 100kg 100%  85m/s 405km/h 100$  30s

REBOL uses recursive descent with backtracking - basically a TDPL 
or PEG model.

its sooo simple, a decimal with any alphanumeric combination glued 
on is a unit.

Not bad, Maxim.

the scientific notation being part of the decimal, you just append 
to that

1.0E-3m  == 1mm

and the current lexical specifically traps this error, so converting 
that error into a new BCD unit type is the logical step for me.  
this replaces money and any other special unit we want.

You wouldn't be able to make a unit a number!, or even a scalar!, 
but otherwise doable. As long as the unit is on the left side of 
a equation it would work. You wouldn't be able to replace money (prefix 
vs. postfix), but otherwise good.

with a few functions, we could even do unit conversions, very easily. 
 units would become some sort of sub-type.  poke a few units as part 
of the default distro and you've got a VERY usefull new functionality.

but with unit, you CAN throw away money.  when parsing, all you need 
is to verify the unit's "moniker" and compare it with "$" if that's 
what you need.

BrianH: I won't be able to make an example (and maybe it's not possible 
now) .. but I was asking because of this maybe stupid idea for "poor 
mans continuations" 


that are built on top of language as a lib (because of rebol powerfull 
treatng of itself): 


- you have a function >>myfunc: func [ a /local b ] [ b: 5  return-cont 
 a + b ] <<
- at runtime when function is called you reach return-cont which:

  - you collect all it's local words and their values into a block 
  (with stack/args etc)  for example [ a 1 b 5  ]

  - you also get current position of a running block (already seems 
  to be possible with stack/block + next )  [ a + b ]

  - you generate a function at runtime that has >>does [a: 1 b: 5 a 
  + b ]<<
  - you return taht function as a normal return value.
this means that this would be possible:
>> cont: myfunc 5
... do some stuff
>> cont 
== 6

any thoughts :) ?

There is one programming language with unit such conversions built 
in, but the language needed to be built around them. We can only 
emulate that in REBOL with functions.

- you generate a function at runtime that has >>does [a: 1 b: 5 a 
+ b ]<<
That is the slow part, and for some code exponentially slow.

Continuations don't work too well in languages with modifiable state 
- look at Icon for the worst example of this.

yes, I know that this would not be anywhere near natively fast.. 
but do you think this would be theoretically possible?

I have to admit I don't know that much about continuations, just 
the surface stuff

do you need continuations to have coroutines?

The generation of a continuation function would only be possible 
with system support, including internal state of natives. Without 
system support it would only be possible for continuations at the 
top level of a function's code (no nested blocks).

aha yes.. you are right.. inside a loop or other nesting this all 
breaks ..

do you need continuations to have coroutines?

 It depends on the system - in some cases it is the other way around.

funy: func [spec body][
	funco spec append copy [
		probe words-of stack/func 1 
		probe stack/args 1
	] body
]

>>foo: funy [x y z][x + y + z]
>>foo 1 2 3
[x y z]
[1 2 3]

In theory you could have continuations in rebcode, using the pseudo-thread 
method.

something like coroutines or other ways to make cooperative multitasking 
would be really nice to have ... "real" threads / processes are just 
one side ot he concurrency IMHO

Steeve, in theory that could work but I've been having trouble getting 
stack/func 1 to work - I think it's buggy.

cool Steeve, I was trying but didn't succeed at that

Janko, you can have cooperative scheduling of real threads - all 
they have to do is cooperate, as long as a thread can pause.

in fact stack/func is useless, because u can use the variable spec 
to get parameters

same result with:

funy: func [spec body][
	funco spec append compose/deep [
		probe [(spec)]
		probe stack/args 1
	] body
]

Only if you know which function you are calling from. I figured out 
the stack/func 1 bug.

but isn't the main difference that coroutines can be made very light 
.. you can have 1000s of them, and with threads creatin of them and 
mem. is more expensive?

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....  ;-)