Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
Hi Jean-Louis,
first: thank you very much for your instructive post!
On 05.06.2011 19:49, Jean-Louis Faucher wrote:
2011/6/5 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at
mailto:rony.flatsc...@wu-wien.ac.at
would it be possible to have the REPLY keyword statement for routines?
If I remove the test context-inMethod() then reply *seems* to work
from a ::routine (tested with a tiny script).
But this is not a proof that it would work all the times.
It crashes when called from an internal routine.
There are quite a few cases, where using routines and multithreading
would seem to be easier to comprehend and to apply, if REPLY was
available for routines.
A good old class method is almost as simple as a ::routine. I don't
see any gain of functionality if we allow to reply from a ::routine,
unless we allow also to expose some variables from a ::routine.
For you, Rick, other Java/C++-savvy programmers and myself: yes.
However, what appears so easy for us, is not necessarily easy for
others, for whom creating a good old class method is a high barrier,
inhibiting (due to steep learning curves, time/resource-pressure etc.)
actually taking advantage of it for their problems.
So a *no* (about easily creating a class method) for programmers who are
not acquainted with OO or have no experience/need creating their own
classes for solving their problems. For this (in my environment rather
large) group, this question is one of usability! It is much easier for
this group to kick off multithreading via a REPLY from within a routine.
For this group this in itself would be very helpful and valuable
functionality, if this multithreading was made available for routines
(if at all possible in a reliable way).
ooRexx is (should be) philosophically following Rexx in its principles
(like human-centricness, dynamic typing, non-signature-based interfaces
etc.).
[digression]
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose
variables from a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated
to the lambda, even when the lambda is called outside the definer's
scope),
then the exposed variables would be the variables to retain in the
closure.
Most of the languages don't require to declare the variables to
capture, but C++ lets /optionally/ declare them, and that remind me
the functionality of our expose :
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) {
total += x; });
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx,
expose is always by reference, right ? Currently, only internal
procedures allow to expose variables, but internal procedures can't be
manipulated like routines...
In the example above, there is a need of closure, because the lambda
is called in the context of the 'each' method, which is not the
context of the definer (i.e. 'each' does not - and could not - expose
the 'total' variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I
don't know if the routines have a similar concept like caller
variables dictionary (cvd ?). And I don't know if that would make
sense to manage synchronisation on this cvd. Probably yes,
synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to
the closure, a routine can be passed as argument to methods which
reply, and then call the routine which will access to the exposed
variable of the closure).
Wow, that sounds very interesting! It would be really great (and
functionality wise very helpful!) to add lambda/block and closures to
ooRexx!
---rony
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
Rony G. Flatscher wrote:
Hi Jean-Louis,
first: thank you very much for your instructive post!
snip
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose
variables from a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated
to the lambda, even when the lambda is called outside the definer's
scope),
then the exposed variables would be the variables to retain in the
closure.
Most of the languages don't require to declare the variables to
capture, but C++ lets /optionally/ declare them, and that remind me
the functionality of our expose :
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) {
total += x; });
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx,
expose is always by reference, right ? Currently, only internal
procedures allow to expose variables, but internal procedures can't be
manipulated like routines...
In the example above, there is a need of closure, because the lambda
is called in the context of the 'each' method, which is not the
context of the definer (i.e. 'each' does not - and could not - expose
the 'total' variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I
don't know if the routines have a similar concept like caller
variables dictionary (cvd ?). And I don't know if that would make
sense to manage synchronisation on this cvd. Probably yes,
synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to
the closure, a routine can be passed as argument to methods which
reply, and then call the routine which will access to the exposed
variable of the closure).
Wow, that sounds very interesting! It would be really great (and
functionality wise very helpful!) to add lambda/block and closures to
ooRexx!
---rony
I seem to remember that Simon Nash stated during his presentation at the
2009 Symposium that a conscious decision was made to NOT implement
closures in ORYX but I don't recall that he gave a reason nor that
anyone asked. Perhaps Rick might recall why. I know I'd be interested
in the reasoning.
--
Gil Barmwater
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
Hi Rony
2011/6/5 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at
would it be possible to have the REPLY keyword statement for routines?
If I remove the test context-inMethod() then reply *seems* to work from a
::routine (tested with a tiny script).
But this is not a proof that it would work all the times.
It crashes when called from an internal routine.
There are quite a few cases, where using routines and multithreading
would seem to be easier to comprehend and to apply, if REPLY was
available for routines.
A good old class method is almost as simple as a ::routine. I don't see any
gain of functionality if we allow to reply from a ::routine, unless we allow
also to expose some variables from a ::routine.
[digression]
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose variables
from a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated to
the lambda, even when the lambda is called outside the definer's scope),
then the exposed variables would be the variables to retain in the closure.
Most of the languages don't require to declare the variables to capture, but
C++ lets *optionally* declare them, and that remind me the functionality of
our expose :
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) { total +=
x; });
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx, expose is
always by reference, right ? Currently, only internal procedures allow to
expose variables, but internal procedures can't be manipulated like
routines...
In the example above, there is a need of closure, because the lambda is
called in the context of the 'each' method, which is not the context of the
definer (i.e. 'each' does not - and could not - expose the 'total'
variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I don't know
if the routines have a similar concept like caller variables dictionary (cvd
?). And I don't know if that would make sense to manage synchronisation on
this cvd. Probably yes, synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to the
closure, a routine can be passed as argument to methods which reply, and
then call the routine which will access to the exposed variable of the
closure).
reply : already discussed
Jean-Louis
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
As far as I recall, REPLY can't be used unless there's some kind of :: directive
in a program (at the bottom!). Always thought that was an unnecessary
restriction.
Mike
_
From: Jean-Louis Faucher [mailto:jfaucher...@gmail.com]
Sent: 05 June 2011 18:49
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native
method ?
Hi Rony
2011/6/5 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at
would it be possible to have the REPLY keyword statement for routines?
If I remove the test context-inMethod() then reply *seems* to work from a
::routine (tested with a tiny script).
But this is not a proof that it would work all the times.
It crashes when called from an internal routine.
There are quite a few cases, where using routines and multithreading
would seem to be easier to comprehend and to apply, if REPLY was
available for routines.
A good old class method is almost as simple as a ::routine. I don't see any gain
of functionality if we allow to reply from a ::routine, unless we allow also to
expose some variables from a ::routine.
[digression]
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose variables from
a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated to the
lambda, even when the lambda is called outside the definer's scope),
then the exposed variables would be the variables to retain in the closure.
Most of the languages don't require to declare the variables to capture, but C++
lets optionally declare them, and that remind me the functionality of our expose
:
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) { total += x;
});
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx, expose is
always by reference, right ? Currently, only internal procedures allow to expose
variables, but internal procedures can't be manipulated like routines...
In the example above, there is a need of closure, because the lambda is called
in the context of the 'each' method, which is not the context of the definer
(i.e. 'each' does not - and could not - expose the 'total' variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I don't know if
the routines have a similar concept like caller variables dictionary (cvd ?).
And I don't know if that would make sense to manage synchronisation on this cvd.
Probably yes, synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to the
closure, a routine can be passed as argument to methods which reply, and then
call the routine which will access to the exposed variable of the closure).
reply : already discussed
Jean-Louis
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
I think you're confusing this with the restrictions for ::requires.
Sent from my iPhone
On Jun 5, 2011, at 3:34 PM, Mike Cowlishaw m...@speleotrove.com wrote:
As far as I recall, REPLY can't be used unless there's some kind of ::
directive in a program (at the bottom!). Always thought that was an
unnecessary restriction.
Mike
From: Jean-Louis Faucher [mailto:jfaucher...@gmail.com]
Sent: 05 June 2011 18:49
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in
native method ?
Hi Rony
2011/6/5 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at
would it be possible to have the REPLY keyword statement for routines?
If I remove the test context-inMethod() then reply *seems* to work from a
::routine (tested with a tiny script).
But this is not a proof that it would work all the times.
It crashes when called from an internal routine.
There are quite a few cases, where using routines and multithreading
would seem to be easier to comprehend and to apply, if REPLY was
available for routines.
A good old class method is almost as simple as a ::routine. I don't see any
gain of functionality if we allow to reply from a ::routine, unless we allow
also to expose some variables from a ::routine.
[digression]
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose variables
from a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated to the
lambda, even when the lambda is called outside the definer's scope),
then the exposed variables would be the variables to retain in the closure.
Most of the languages don't require to declare the variables to capture, but
C++ lets optionally declare them, and that remind me the functionality of our
expose :
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) { total
+= x; });
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx, expose is
always by reference, right ? Currently, only internal procedures allow to
expose variables, but internal procedures can't be manipulated like
routines...
In the example above, there is a need of closure, because the lambda is
called in the context of the 'each' method, which is not the context of the
definer (i.e. 'each' does not - and could not - expose the 'total' variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I don't know
if the routines have a similar concept like caller variables dictionary (cvd
?). And I don't know if that would make sense to managesynchronisation on
this cvd. Probably yes, synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to the
closure, a routine can be passed as argument to methods which reply, and then
call the routine which will access to the exposed variable of the closure).
reply : already discussed
Jean-Louis
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native method ?
Does it work without a directive? I thought I had tried that.[Sample code
welcome -- no hurry.]
Mike
_
From: Rick McGuire [mailto:object.r...@gmail.com]
Sent: 05 June 2011 20:45
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Reply in routines,possible ? (Re: Reply in native
method ?
I think you're confusing this with the restrictions for ::requires.
Sent from my iPhone
On Jun 5, 2011, at 3:34 PM, Mike Cowlishaw m...@speleotrove.com wrote:
As far as I recall, REPLY can't be used unless there's some kind of :: directive
in a program (at the bottom!). Always thought that was an unnecessary
restriction.
Mike
_
From: Jean-Louis Faucher [mailto:jfaucher...@gmail.com]
Sent: 05 June 2011 18:49
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Reply in routines, possible ? (Re: Reply in native
method ?
Hi Rony
2011/6/5 Rony G. Flatscher mailto:rony.flatsc...@wu-wien.ac.at
rony.flatsc...@wu-wien.ac.at
would it be possible to have the REPLY keyword statement for routines?
If I remove the test context-inMethod() then reply *seems* to work from a
::routine (tested with a tiny script).
But this is not a proof that it would work all the times.
It crashes when called from an internal routine.
There are quite a few cases, where using routines and multithreading
would seem to be easier to comprehend and to apply, if REPLY was
available for routines.
A good old class method is almost as simple as a ::routine. I don't see any gain
of functionality if we allow to reply from a ::routine, unless we allow also to
expose some variables from a ::routine.
[digression]
Instructions that can be called only from methods :
expose : I still don't understand why it's not possible to expose variables from
a ::routine...
If we do a relation with
- anonymous inline functions (often called lambda or block),
- outer environment (the variables used by the lambda, which are not
parameters),
- and closure (which is the outer environment which remains associated to the
lambda, even when the lambda is called outside the definer's scope),
then the exposed variables would be the variables to retain in the closure.
Most of the languages don't require to declare the variables to capture, but C++
lets optionally declare them, and that remind me the functionality of our expose
:
- c++
std::vectorint some_list;
int total = 0;
std::for_each(some_list.begin(), some_list.end(), [total](int x) { total += x;
});
- oorexx (with extensions)
some_list = .array~of..
total = 0
some_list~each([expose total; total += arg(1)])
-
C++ lets capture a variable by value or by reference. In ooRexx, expose is
always by reference, right ? Currently, only internal procedures allow to expose
variables, but internal procedures can't be manipulated like routines...
In the example above, there is a need of closure, because the lambda is called
in the context of the 'each' method, which is not the context of the definer
(i.e. 'each' does not - and could not - expose the 'total' variable).
forward : nothing to say
guard : in relation with the object variables dictionary (ovd). I don't know if
the routines have a similar concept like caller variables dictionary (cvd ?).
And I don't know if that would make sense to manage synchronisation on this cvd.
Probably yes, synchronisation would be necessary if we allow
- reply and expose in ::routine
- expose and closure (even if no reply in ::routine, because thanks to the
closure, a routine can be passed as argument to methods which reply, and then
call the routine which will access to the exposed variable of the closure).
reply : already discussed
Jean-Louis
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
