[EMAIL PROTECTED] wrote:
>>1. What are the `correct' rules for function application,
>> variable scoping, and objects?
Gabriele replied:
>They're amazingly simple, at least in my speculation.
[speculation deleted]
The point is that this is pure speculation! I understand that
this seems to be what the current implementation is doing, but
without an `official' description, this speculation may or may
not be what is `intended'.
>>2. Are these rules useful?
>Yes.
I agree that these rules are useful for simple cases. However,
in complicated cases, like functional composition, the trick of
modifying an existing, possibly shared, context is a hinderance.
>>3. Is the current *implementation* of REBOL faithfully following
>> these rules?
>Yes. (Well, I created the rules looking at the implementation...)
You are clearly in the `Gump' camp: REBOL is as REBOL does.
>>4. Is the *next* implementation of REBOL likely to behave
>> differently?
>I don't think so.
Plus ca change...
>>The current implementation seems to be fairly well behaved as long
>>as you don't attempt to return functions outside of the scope in
>>which they are defined.
>I don't understand what you are saying here, sorry.
I mean that top-level functions seem to be useful as first-class
functions, and you can call nested functions, but if you attempt to
return a nested function as a value, you can't use it in a meaningful
way, and REBOL eventually crashes.
>> However, functions aren't
>>first-class objects if you can't return them
>>as values.
>They are, and you can. Trust me. :-)
Nested functions with free variables don't work right if you
do this, and REBOL eventually crashes.
>>Every version of REBOL has either made subtle or drastic changes in
>>how variables are scoped.
>That's false. It never changed, if not from 1.0 to 2.0 (EVERYTHING
>changed...).
I'd call `EVERYTHING' drastic.
I'm exagerating, as are you. REBOL 2.0.1 shared loop variables
(thus making loops non-reentrant) where subsequent versions don't.
>>If there are `correct' rules for function application, variable
>>scoping, and objects, why is REBOL Tech. so adamant about keeping
>>them secret?
>They do not have the time. Do realize that they're not a big
>company.
Bullshit. I have no idea how big they are, but I've seen quite
a few descriptions of what REBOL (the language) seems to be doing
in the archive, and not once has REBOL (the company) said: `Yes.
That's the correct model' or
`That's very close to what we want to be doing.' or `The sharing
of variable bindings across non-recursive calls is an implementation
artifact.'
>>Is the GC buggy when it collects contexts or do contexts have a
>>limitied lifetime?
>There's a bug. Contexts have undefinite extent.
Again, how do you know this? Maybe it is `incorrect' to return
an inner function and the bug lies not in the GC, but in the
interpreter for failing to detect this error. Maybe this error is
too expensive to check, so REBOL relies on users to `do the right
thing'.
>>Jeff's code doesn't work in this case:
>>
>> funny-func: composite
>> func [x] [x + 1]
>> func [y] [y * 2]
>That's just because it requires words, not functions, as
>arguments. Change it to:
>composite: func [f g][func [x] compose [(:f) (:g) x]]
>and it will work.
Jeff is already the self-acclaimed winner of this contest.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
