Some more thoughts on closures, now that I've had my shower (I get some of my best ideas in the shower :-)).
Another somewhat related area I've been mentally toying with is introducing the concept of a variable reference. This would allow call-by-reference semantics on calls/methods. With this enhancement, there's a new "variable reference" class. The only way to create a variable reference is via the special syntax "[name]". Where name is the name of a valid Rexx variable. At present, I was going to limit this to simple and stem variables. A variable reference has just a couple of methods, value() and "VALUE=". However, it can be coupled with USE ARG to create actual variable aliasing: USE ARG [foo] says that we're expecting a variable reference object as the first argument, and this will be aliased to the variable FOO. From that point, you can just say foo foo = somethingElse and you are in reality accessing variable NAME back in the caller's context. The [] syntax will work well, if defined carefully to disambiguate the usage as method names. This processing can even be extended to message assignment syntax to allow [foo~name] to be passed as a reference. As I was thinking about your proposal, and what I wanted to do with variable references, I realized that the variable reference objects are just a specialization of what you specified for closures. The syntax [expr] would create a deferred evaluation. If the "expr" is a valid assignment left-hand-side, then this is a variable reference object that supports assignment. Otherwise, this is an expression reference object that only supports evaluate. This really becomes rather clean. There's an additional type of closure that's used in other languages like groovy, which is an actual code snippet that can be passed around, but executes in the variable context of place where it was created. This is similar to your proposal, but the code is not limited to just a single expression. This can be a very handy (but somewhat confusing) feature to have. That one has a few more syntax challenges than this. Rick On Tue, Jul 22, 2008 at 6:27 AM, Rick McGuire <[EMAIL PROTECTED]> wrote: > I've been giving some thought to whether closures could be added to > the language for some time, but the issues generally lie on the > calling end. That is, what is the syntax to be used that would allow > a closure to be created without cluttering up the language with lots > of special exceptions or awkward syntax. Ideally, a closure would be > something that would just be an extension of normal expression syntax. > Closures would be assignable to variables and, of course. allowed as > method arguments. Implemented that way, there's no additional > overhead needed on the argument calling mechanisms. So far, I've not > found a syntax that I'm happy with. > > There are other side issues that need to be addressed, such as > ensuring that the closure somehow becomes invalid when the environment > where it was created is no longer valid, or the more interesting case > of a closure passed to a method that does an early reply...now the > closure will be executed on an entirely different thread. > > This is an interesting idea, but not one I'm prepared to jump on and > accept until all of the implications are written down and discussed. > Right now, there are lots of more well-defined enhancements on my todo > list. If you'd like to get involved in any of these, just speak up > and I'll suggest a few. > > Rick > > On Tue, Jul 22, 2008 at 5:01 AM, Jean-Louis Faucher <[EMAIL PROTECTED]> wrote: >> >> Sorry, my previous mail was sent from a flashmail, was a bad idea ! I hope >> this one will be more readable... >> >> As other users (see comp.lang.rexx/2005-11/msg00065.html), I use sometimes a >> function iif which on the basis of a condition selects between two values : >> iif: >> use strict arg condition, iftrue, iffalse >> if condition then >> interpret "return" iftrue >> else >> interpret "return" iffalse >> >> I see two drawbacks with this function : >> The caller must surround the 2nd and 3rd argument by quotes, to pass a >> string to the function. Example : say iif(s == .nil, 's', 's~id') >> The whole scope of the caller must be visible, to let the evaluation have >> access to all the variables of the caller. So I can't implement this >> function as a procedure or a routine or a method. And I can't put it in my >> library that I requires from my scripts. >> >> I had a look at the function RexxActivation::run (putting a breakpoint here >> is very instructive). >> I see that each instruction is evaluated by : nextInst->execute(this, >> localStack) >> It seems that each instruction is in charge of the evaluation of its >> arguments, using : result = this->expression->evaluate(context, stack) >> >> Could we imagine that such a behavior is possible at the level of user rexx >> code ? The not-evaluated-expression passed to the rexx code should bring the >> context and stack with her, to let the user write >> expression->evaluate() >> >> A not-evaluated-expression is not of type String. Should be of a new type >> (Closure ?) which supports the method evaluate(). >> >> Example : >> >> iif: procedure >> use unevaluated arg condition, iftrue, iffalse >> if condition->evaluate() then >> return iftrue->evaluate() >> else >> return iffalse->evaluate() >> >> Here " unevaluated " is a keyword to indicate the deferred evaluation of the >> arguments. >> I can use a procedure or routine or method since the evaluation of the >> expression is done in the caller's context. >> >> The caller calls the function without surrounding the expressions in quotes >> : >> say iif(s == .nil, s, s~id) >> >> And there is no error like Object "The NIL object" does not understand >> message "ID" when s is nil. >> >> Jean Louis >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
