Thanks Rick,
I was limited to passing arguments, but it's true that the problem is
wider... I had the Lisp approach in mind (fsubr), but the Smalltalk
approach based on code blocks is also a candidate approach, and probably
others... (I have only a superficial knowledge of these subjects :-)
David was faster than me : Is it possible to have the list of well-defined
enhancements on your todo list ?
Jean Louis
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
David Crayford <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
22/07/2008 13:15
Please respond to
Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
To
Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
cc
Subject
Re: [Oorexx-devel] Deferred evaluation of arguments ?
I love closures! I've only used them hacking about in groovy but they're
really nice. What else is on your todo list? Have you
given aspects any thought?
Rick McGuire 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
>> Oorexx-devel@lists.sourceforge.net
>> 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
> Oorexx-devel@lists.sourceforge.net
> 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
Oorexx-devel@lists.sourceforge.net
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
