World: r3wp

So, my question was, how would you implement F1, F2 and F3 in your 
hypothetical language to get:

>> f2 f1
== 1

>> f3 f1
== 3

It is not simpler, you just are forbidding a useful feature.


If closure! could be avoided, then the C source for the language 
is simpler. That's what I mean. If the closure functionality can 
be achieved by a mezzanine, nothing has been forbidden. Of course, 
if the language doesn't have problems with keeping the C source simple, 
a closure! datatype could be included, as it would possible be faster.

I already gave examples to do that. They were:

>> context [a: 1 set 'f1 compile [a]]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 1
>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


I haven't finished reading about CLOSURE, so maybe it can be even 
simpler.

Isn't it correct, that the CLOSURE mezzanine in R2 only work (without 
using object! in any way), because functions are already closures 
in R2?

Nope.

Yeah, it is. Else the CLOSURE mezzanine would work in R3 with R3's 
functions, and it doesn't.

Why does R2's CLOSURE parse of set-word! in the spec? Doesn't make 
sense.

parse *for* set-word!

It would be easier in R2 to create CLOSURE this way:

>> closure: :func
>> f: closure [a b] [[a + b]]
>> do f 1 2
== 3

R3 has two context types: object and function. R2 only has one context 
type: object. This is why you can create a persistent context using 
a function in R2, while you can't in R3.

I know. So functions are closures in R2.

R2's functions have object contexts that are reused on subsequent 
calls, so you can't count on the context to persist if the function 
is called again. That is the difference between R2's functions and 
R3's closures.

Creating a new context every time the function is called is the whole 
point to closures, the only reason that you would use them instead 
of a function.

The PARSE statement in CLOSURE creates the code for a call to a function 
that the resulting outer function creates every time it is called. 
If you want to understand what the PARSE statement is doing, make 
a function with CLOSURE and look at its source.

Why does R2's CLOSURE parse of set-word! in the spec?


The set-word! in the PARSE spec is a special-case, so that set-words 
aren't counted in the set word any-word! portion of the next alternate 
in the rule. Set-words in function specs are keywords for special 
purposes in function creation (just return: in R2), they don't refer 
to parameters, and the other word types are collected as parameters.

Creating a new context every time the function is called is the whole 
point to closures

And R2 is not doing this with its functions?

>> f: func [a] ['a]
>> w1: f 1
== a
>> w2: f 2
== a
>> get w1
== 2    ; note that the value has changed

>> c: closure [a] ['a]
>> w1: c 1
== a
>> w2: c 2
== a
>> get w1
== 1    ; note that the value persists

>> source c

c: func [a][native action function! [[throw] :a [any-type!]] ['a] 
a]

Those first three values in the source of C are direct references 
to the functions DO, MAKE and the type function!, so there are no 
word conflicts.

(just return: in R2)

Can you create a function with a return: set-word! in the spec?

The type is reserved for future use. If it's an error, the MAKE function! 
at the end will catch it.

Where did you get this info?

Interesting example, you gave with W1 and W2. Funny how recursive 
functions works then!?

From Carl, years ago. Set-words in function specs are supposed to 
be used for more in R3 later.

Did Carl write about the set-word! in function spec anywhere?

There is a bug in CLOSURE though. This line:
    insert tail bdy to word! :word

will have problems with some datatypes. I'll fix it for the next 
version.

Set-words in function specs are used by the routine! type now.

It's not so good and almost sad, that Carl used so much energy to 
include new stuff (like also routine!) instead of concentrating on 
making the old stuff (from R2) work correctly first.

And now he's burnt out?

R2 has routine!, R3 doesn't.

I would expect anybody to be burnt out when taking that approach 
to things. It's like building a skyscraper by loosely make all floors 
first, then trying ot fix everything. Better to get first floor solid 
before moving on.

Recursive functions in R2 work by pushing the block of values in 
a context onto a stack during the recursive calls, then popping them 
off on return. In R2, function contexts are stack-relative, which 
makes word dereferencing 27% slower relative to object contexts, 
but function calls in general faster. Closures bind to object contexts, 
which are recreated with every function call.

R2 has routine! from what version of R2?

Any version with library support.

:) And when did library support get in?

I don't know, a little less than 10 years ago?

Whenever /View/Pro or /Command was invented.

Ok, that's old then.

Does routine! work flawlessly?

Don't know. R2's library support was never flexible enough for me 
to be able to use. Others seem to be able to make it work.

RAMBO holds 15 tickets, when searching for "routine!". 9 are Reviewed, 
6 Built.

Oldest dated 20-Oct-2004, newest 18-Apr-2010.

I would say, we desperately needs a replace for REBOL, so all the 
man-years of work, people have done in creating software with it, 
isn't wasted. It's not all wasted, nomatter what happens, as many 
things work and is used, but many would like to move on, I guess.

I prefer to think of a combination of R3 and Red as potentially being 
that replacement, but other people may have other plans.

Never mind what I said about the bug in CLOSURE. It's not a bug.

Geomol: syntax is insignificant, translating from one to another 
is easy.


Anyway, the problem with a Scheme using REBOL-like syntax is that 
you give up dialecting (static binding is pretty important for that).

I found an bad effect of not binding words in blocks at all, before 
the block is evaluated. Functions like LOOP take 2 args, count and 
block. By not binding the block content before it's evaluated, the 
count arg local to LOOP is found, if a count var is used in the block.

So I guess the REBOL early bind of words is better.

LOOP's count arg is not bound to the block of code, so it is not 
local. This is why LOOP is the fastest loop. REPEAT is the version 
of LOOP with a bound local arg.

The backside of REBOL's binding is all the unset words, we start 
out with. R2 has 1865 unset words registered in system/words. They 
can be seen with this code:


 foreach w first system/words [if unset? get/any to lit-word! w [prin 
 [w ""]]]

but doesn't this list disapear with the new multi-level booting of 
R3?  since those words are now not sent in the user context but stay 
in their lower levels?