Talk:Scoping in Rebol

From DocBase

This is the talk page for Scoping in Rebol

Funct, Function, Func

I'm very glad to see FUNCT making it into R2, but I'm very sad to see it's called FUNCT. Almost anything would be better than that. Even LAMBDA or perhaps repurpose the FUNCTOR name?

What I've had as the ideal in my view would be to replace the largely useless "FUNCTION" construct from R2. I also feel that if CLOSURE and CLOS had the same duality then the whole thing would seem clearer... (the longer name is for the thing that does the extra stuff and your shorten it if you're doing optimizations.)

It's difficult if one has spent a decade working in a language to realize how small things like this can turn people off, but I'm convinced it does. I'm wondering if there is any hope for a "R2 compatibility mode" vs. an "clean R3 mode" where decisions like this (and perhaps some others) could be revisited. Fork 18:56, 2 January 2010 (EST)

The terms "lambda" and "functor" have really specific meanings in the CS community, and neither of them apply here. We used to have a FUNCTOR function that was appropriately named, but unused in a year of existence so we dropped it. There is no theoretical model that covers the various tricks that FUNCT does, which makes it an excellent candidate for using a strange name that doesn't mean anything before now, and then just having that name be the way to refer to the concept from now on. That is the general method for dealing with a new concept. We don't want to use "function" because it also has a specific, more generic meaning and FUNCTION has been in REBOL for 10 years, and it would be bad to break - it's not useless, it's used. BrianH 20:13, 2 January 2010 (EST)

Regarding CS community consensus, I did look that up before making the suggestion:

"A lambda is.. not quite so well defined as far as computer science goes. A lot of languages don't even use the term; instead they will just call them closures or anon functions or invent their own terminology. In LISP, a lambda is just an anonymous function. In Python, a lambda is an anonymous function specifically limited to a single expression; anything more, and you need a named function. Lambdas are closures in both languages." source

"A Function Object, or Functor (the two terms are synonymous) is simply any object that can be called as if it is a function. An ordinary function is a function object, and so is a function pointer; more generally, so is an object of a class that defines operator()." source

I agree to some extent that it is good to invent new terms for things when they are new to avoid people thinking they understand something they don't. But on the other side of this equation, the very premise of Rebol is that words are given meaning from their context. Moreover, I don't think what Rebol currently calls a "function" has a more legitimate claim on being the official application of the word in Rebol—quite the contrary. Assignments are usually assumed to be local in almost every language I've used (unless some specification to the contrary is provided). Fork 21:23, 2 January 2010 (EST)

OBJECT Modifying its Spec Block

This is accidents waiting to happen. If it were necessary, it should be documented clearly when you type help object...as it is there's no mention of "(Modifies)".

The only user-oriented reason I can imagine that MAKE OBJECT! would not internally simulate a "virtual none" is to keep CONTEXT in parity with DO:

>> do [a: 10 b:]
** Script error: b: needs a value
** Where: do
** Near: do [a: 10 b:]

>> context [a: 10 b:]
** Script error: b: needs a value
** Where: make context
** Near: make object! blk

If that's not important I'd say MAKE OBJECT! should emulate the NONE internally. Fork 07:31, 3 January 2010 (EST)

The behavior of the OBJECT function hasn't achieved consensus yet, which is why it wasn't backported from R3 to R2 yet. There is a possibility that MAKE OBJECT! will be modified to behave that way instead, without needing to modify the code block. However, the modifying behavior of OBJECT is not an accident, it is an intentional choice to avoid block copies for efficiency and predictability reasons. Many functions in REBOL are modifying for that reason; it is never accidental, it is part of the core design model of the language. BrianH 17:35, 3 January 2010 (EST)

Throwing aside backward compatibility for a moment, I find myself wishing for context to return the last expression value instead of the object itself. e.g.

>> a: 100
>> result: context [
           a: 200
           a + 1
       ]
== 201
>> print a
100

Then it would make particular sense to disallow trailing set-words. Also, if you wanted to return the context itself you'd just make your last expression "self". Fork 13:06, 4 January 2010 (EST)

If it is important and CONTEXT/OBJECT really must behave differently (despite passing through the common interface bottleneck of MAKE OBJECT!), why not just remove the NONE after you've added it?

object: make function! [[
    "Defines a unique object and assigns NONE! to any trailing SET-WORD!s in the spec block."
    blk [block!] "Object words and values."
][
    also make object! append blk none remove back tail blk
]]

Anyone concerned about the performance of a remove AND an add can put none in their own spec and use CONTEXT or MAKE OBJECT! Fork 07:31, 3 January 2010 (EST)

Not a bad idea. The addition of a none on the end doesn't affect the execution of the code, but it could be considered a memory leak if OBJECT is used more than once with the same code block. It shouldn't be too much overhead. BrianH 17:43, 3 January 2010 (EST)

I wondered if there was something like ALSO, just didn't know what it was called. Yes, the leak is the concern, and I think that if it were patched to put it back then the documentation is more sensible and the rest is less of a big deal. Fork 13:06, 4 January 2010 (EST)