Hi, <Holger>
It is the result of REBOL being an interpreter, not a compiler. A compiler examines the complete body of a function before generating code, so the variable declaration can be anywhere. For an interpreter there are only two options: 1. Make the context of a function "static", i.e. defined when a function is declared. In that case declarations have to be explicit, i.e. during the execution of "func" or "function", when the function is defined, all variables must be known. If declarations can appear in the body of a function then there is no way for "func" to know a list of all variables. Scanning the function body is not an option, because declarations could be "hidden", e.g. with something like [do rejoin ["a" ": " "1"]], i.e. there is no way for "func" to know about all declarations without actually executing the function. </Holger> Although that sounds logical, it is not the whole truth. Compare the way how USE declares the local variables (the declarations don't appear in the BODY argument) vs. the way how CONTEXT declares the local variables (the declararions appear in the BLK argument). That surely isn't a non-option. <Holger> 2. Make the context of a function "dynamic", i.e. make it empty when a function is declared, and extend it at run-time as needed. This is not how REBOL currently works. Allowing this kind of model would require significant changes to the interpreter. It is the same problem as "extending" the context of objects. </Holger> I am not a member of the "Object Extenders Club", nevertheless, the dynamic function context surely *is* useful sometimes. Such functions (slower than their native counterparts could be) we can create in Rebol even now. <Holger> > What I would like to see is another shortcut to > creating local variables in any context (function, > innerfunction, loop). The obvious way I see of doing > this is as follows: > > > myfunc: func [][ > localvar:: $25 Nooooo. Please do not do that :-). You did not just create a notation with that, you actually created a new datatype: a set-set-word!. We do not like to create new datatypes unless it is really necessary and the exact meaning, scope, usefulness etc. are very well defined and can be clearly demonstrated. Creating a new datatype only to shortcut variable declaration seems ... inappropriate, for lack of a better word :-). -- Holger Kruse [EMAIL PROTECTED] -- </Holger> I think, that it can really be useful, although the proposal made by Rishi is not a complete thing. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
