Bonsoir Jean-Louis:
first, *many thanks* for your helpful comments and explanations !
[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. The same is true for the names of methods standing for
higher-order functions,
or"~{}" instead of "~do()" or "~run()"; although, I must admit, it is a very
interesting idea that
shows how innovative you are, seriously! And of course, as it is your sandbox,
you are of course
absolutely entitled to do whatever you feel and helps you, not necessarily
lurkers!]
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'?
* More a comment, than a question: quite a few years ago the idea of
introducing a directive that
allows literals was brought up (I think by David Ashley or Rick McGuire),
which would allow to
save resources (like bitmaps, sound-bites, etc.) within the sourcecode of a
Rexx program
transforming the binary data with .String's encodeBase64 method. The
running program would
become able to fetch that "literal" block and apply "decodeBase64" to get
at the binary data.
Your RexxBlock allows for such a technique, e.g.:
/* a base64 encoded literal stored in a Rexx block */
encodedBase64Msg={ "SmVhbi1Mb3"
"VpczogeW91"
"ciBSZXh4Qm"
"xvY2tzIHJv"
"Y2sh" }
say "encodedBase64Msg:" encodedBase64Msg
say "now showing the decoded base64 message stored in a RexxBlock:"
say decodeRexxBlock(encodedBase64Msg)
::routine decodeRexxBlock
use arg rexxBlock
m=.MutableBuffer~new
do line over rexxBlock~source -- iterate over lines in RexxBlock
l=line~strip~strip('B', '"') -- strip blanks and then quotes from
both sides
if l="" then iterate -- skip empty lines
m~append(l)
end
return m~string~decodeBase64
Running the above program yields the following output:
encodedBase64Msg: a RexxBlock
now showing the decoded base64 message stored in a RexxBlock:
Jean-Louis: your RexxBlocks rock!
Questions ad coactivity:
* Is a "coactivity" always a RexxBlock?
* What is the difference between "::coactivity" and "::closure" and
"coactive.closure"?
* Whyt is the difference between "::method" and "::method.coactive", as well
as "::routine" and
"::routine.coactive"?
* Why is there a .yield[] (a class named yield with a method named "[]")?
What does "yield" do?
* 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?
* 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?]
Maybe these are too many questions already, so I stop and hope that you get
some time for answering!
Regards,
---rony
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
