Bonjour Jean-Louis,
not having referred to some of the experimental features of your sandbox
version of ooRexx the
(wrong) impression might be evoked, that they are not interesting, hence an
attempt to briefly
comment my personal impressions:
* "ooRexxShell": that is a *great* rexxtry.rex replacemtn, with color
highlighting, history,
globbing and requiring up-front important Rexx packages, as well as giving
interesting
information (like number of coactivity threads active).
* "Extensions of predefined classes": *great, great, great*!
* "Concurrency trace": an extremely important extension to Rexx trace when
debugging concurrency
issues that simply could not be debugged in the current trace! Really a
*great* extension.
* "NOMACROSPACE": interesting findings and interesting solution (I have never
used a macrospace so
I will disable that by default, gaining an external function lookup speedup
of a factor of
five), with a remarkable increase in lookup speed!
* "NOCOMMANDS": very interesting idea, have a few uses for this. (Clever idea
to place the command
(expression) into the variable 'result', matches nicely in the case of
NOCOMMANDS.)
* "Parser : Refinement of tokens 'subclass' attribute": unfortunately, I was
not able to get to
see this. I defined (Windows) RXTRACE_PARSING=ON, but unfortunately it
seems that no dumping of
the clauses and tokens take place.
* "Parser : arg(...)": hmm, sounds reasonable.
* Trailing "=": this is an interesting, innovate idea, especially if
interactively debugging on a
shell like ooRexxShell.rex! Not sure, whether it should be active by
default or needs explicit
activation via an option keyword (e.g. TRAILINGEQUAL_IS_SAY)
* "Parser : = ==": not sure what the problem is and what changes you
implemented. What behaviour
is systematically changed here?
* "Parser : Message term": interesting idea, not sure whether really needed
(looks a bit awkward:
sending a message to an object, but not giving that message an explicit
name; one all of a
sudden must remember such a short-cut to become able to understand/read
code employing it;
*however*, I would prefer ".yield~()" to ".yield[]" which looks even more
awkward, although this
is possible already with ooRexx).
* "Blocks (source literals & doers)": this just rocks!
* Closure, coactivity: with your explanations on the developer list, they are
really great,
opening up a whole new world of coding possibilities making it easy using
Rexx to exploit these
concepts!
* BTW your thread local idea is just *great* (cf. class .Activity)! That is
exactly what I was
requesting, but have never thought of such a simple and elegant solution!
Before being able to comment/ask questions on "Partial arguments" and the
latter concepts in the
"readme.txt", I have to study them. :)
Really *great* work, Jean-Louis, thank you very much to share it with us!
---rony
------------------------------------------------------------------------------
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
