Guten tag Rony
[One comment ad abbreviations: maybe it would be good for mere mortal Rexx
> programmers ;) to spell out keywords in full and not abbreviate them (the
> same for values for attributes like 'kind' in RexxBlock). The abbreviations
> just save very few keystrokes while writing, but make the programs quite
> hard to read and therefore hard to comprehend, if one is not always working
> with the features where these abbreviations are possible. Some questions
> probably are needed because of the use of abbreviations.
>
Yes, you're right, I will avoid abbreviations when writing examples.
Abbreviations are useful when writing one-liners, which happens all the
time when using ooRexxShell.
By the way, I will commit soon a version of ooRexxTry.rxj which preloads
all the packages, like ooRexxShell. Multiline blocks are possible with
ooRexxTry.rxj :-)
> The same is true for the names of methods standing for higher-order
> functions,
>
I suppose you do reference to ~map, ~mapC, ~mapCI, mapCR etc...
If you look at the file diary.txt, section 2011 oct 16, you will see why
the method names are like that.
See
http://en.wikipedia.org/wiki/Fold_%28higher-order_function%29#Folds_in_various_languages
Some languages use just one letter to make a distinction between several
methods. Ex with Haskell : foldl, foldr, foldl1, foldr1.
Of course, some languages are more verbose, but this is not the style I
prefer.
> or"~{}" instead of "~do()" or "~run()";
>
The notation f~(), this is one of the two possible notations if you want
something close to the "real" function call f(). The other possible
notation is f[] as it's done in pipe.rex or with .yield[].
I discovered a few days ago that the notation ~() had been considered in
the early days of Oryx.
http://www.docstoc.com/docs/53779711/An-Object-REXX-Retrospective
page 13 :
*1989: The Essential Core
Some things didn’t survive: closures, keyword arguments, [] for pointers
and reference arguments, assertions, coercion, ~* and ~&, ~()
*
> Questions ad blocks:
>
> - defining a block like:
>
> a={x=1
> y=3
> say x/y}
>
>
> then sending it the message "~do" or "~()" does not yield an
> execution. When sending the Rexx block 'a' the message "rawExecutable"
> returns in this case a routine object, which can be run by sending it the
> "call" message.
>
> However, I was expecting to be able to send "~do" or "~()" to it. How
> can I get a doer from the Rexx block 'a' that understands 'do'?
>
>
Did you requires "extension/extensions.cls" ?
The support for ~() or ~do is not part of the predefined classes.
On the other hand, ~rawExecutable is predefined.
Questions ad coactivity:
>
> - Is a "coactivity" always a RexxBlock?
>
>
A RexxBlock is a factory of coactivity (among others) when the tag is
::coactivity or ::routine.coactive or ::method.coactive. But you don't have
to always use a block. You can use directly a routine or a method or a
message.
See the method ascendingValues in
http://oorexx.svn.sourceforge.net/viewvc/oorexx/sandbox/jlf/samples/concurrency/binary_tree.cls?view=log
Here, the coactivity is created explicitely, passing as parameters the
message "visitAscending" and the root object of the binary tree.
>
> - What is the difference between "::coactivity" and "::closure" and
> "coactive.closure"?
>
> A ::coactivity remembers its internal state. It can be called several
times : The execution is resumed after the last .yield[].
A ::closure remembers its outer environment. It can be called several times
but the execution is always from the start of the code.
A ::closure.coactive is both a closure and a coactivity. The method
yield.upto in functional.cls returns a coactive closure.
> - Whyt is the difference between "::method" and "::method.coactive",
> as well as "::routine" and "::routine.coactive"?
>
>
Same reason as previously for closure. If you want a routine or method
which remembers its internal state and can be resumed, then you have to
declare it coactive.
> - Why is there a .yield[] (a class named yield with a method named
> "[]")?
>
>
.yield[args...] is a shotcut notation for .Coactivity~yield(args...) where
"[]" is a class method. Some languages like ruby or python have a yield
statement and I wanted to emulate this statement, without modifying the
interpreter... At that time, I did not yet add support for ~(), so [] was
the only possible shortcut (borrowed from Rick's usage in pipe.rex).
>
> - What does "yield" do?
>
> "yield" lets the producer return a result to the consumer.
On the consumer side, the consumer uses
producerResult = aCoactivity~resume(args...)
On the producer side, the producer uses
clientArguments = .yield[args...]
"yield" can be called only from within a coactivity, i.e. the first call in
the call stack must be aCoactivity~start.
Try that from ooRexxShell : .yield[]
You will have the error "yield can be used only from a coactivity".
> - How does the following example from your readme.txt file
> work/execute?
>
> v = 1
> w = 2
> closure = {::closure.coactive expose v w ; .yield[v] ; .yield[w]}~doer
> say closure~do -- 1
> say closure~do -- 2
>
> Would a third invocation by sending do work?
>
> Try that from ooRexxShell (enter each line one by one) :
v = 1 ; v = 2
closure = {::closure.coactive expose v w ; .yield[v] ; .yield[w]}
closure=
--> you see [a RexxBlock id#_263270149] and #Coactivities: 0, the thread is
not started.
closure~do=
--> you see [1] and #Coactivities: 1, the thread has been started by the
the first call.
closure~do=
--> you see [2] and #Coactivities: 1
closure~do=
--> you see [no result] and~# Coactivities: 0, the thread is ended
closure~do=
--> you see [no result] and~# Coactivities: 0
etc...
If you run the code above from a script (only two invocations), you will
see that the script doesn't terminate. This is because the coactivity's
thread is not ended.
A third invocation "say closure~do" will raise "No result object".
A third invocation "closure~do" will not raise an error, and the program
will terminate, because the coactivity's thread is ended.
If you want to be sure that your program is not blocked at the end of
execution, then put this line at the end of the script :
.Coactivity~endAll
This is what is done in ooRexxShell. Even if the counter #Coactivities is
not zero, you can leave ooRexxShell by typing "exit".
A coactivity which is no longer referenced is automatically stopped when
GC'ed. So no need to worry about the termination of a coactivity.
> - Are there any other methods going together with "yield"? [You seem
> to use "trampoline", "partial", "resume" ("lazy repeater"), "each", "map",
> "reduce", "times" somewhat in this context? What is the purpose/difference
> of these methods?]
>
>
A coactivity supports the method ~supplier.
So it can be seen as a collection (black box, you don't have to worry about
"yield" here).
But, unlike a collection's supplier which builds a snapshot of the
collection, a coactivity's supplier does not create a snapshot of the
values generated by the coactivity. It's a lazy supplier, which resumes the
coactivity only when needed (i.e. when aSupplier~next is called).
Using a coactivity and the class .File, you can implement a FileTree which
returns each file one by one, and wait for your next request before
searching the next file.
Jean-Louis
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
