Hi Mike,
On 05.09.2020 21:48, Mike Cowlishaw wrote:
> Rony, this was added to NetRexx back in the 1990s.
yes, this also meant that translating NetRexx to Java would be
straight-forward, but NetRexx broke
compatibility with Rexx in that respect (which has not been a problem).
Also, another important feature that you added was ...catch...finally, which
IMHO is much easier to
understand and to code.
(Programmers used to try/catch/finally are sorely missing it when they look at
ooRexx which only
offers the classic Rexx signal construct, which is difficult to understand for
them.)
> ooRexx does it differently, for whatever reason.
Well, ooRexx does it exactly like you defined it for Rexx, such that ooRexx
remains able to run Rexx
code unchanged and the way Rexx does it.
(NetRexx is not compatible to Rexx, hence you were free to change the specs
according to your
expertise and the requests/demands from the potential (Java) user base.)
> Whatever the case, it is always better to 'spell out' the short-circuits in
> the code rather than
> rely on weird notations, surely? That way, people who read the code later
> can see exactly what
> the programmer intended, rather than having to infer it from some piece of
> code and notation that
> quite possibly was wrongly coded in the first place.
This sounds tempting. :)
OTOH there must be a reason why programmers have been asking short-circuiting
from ooRexx, not?
---
This is a simplified case of demonstrating the short-circuting of conjunctions
which is already
available in ooRexx:
if a=.true , b=.false , c=.true then
do
say 'hi, there'
... more code ...
end
This would be the equivalent in Rexx:
if a=.true then
do
if b=.false then
do
if c=.true then
do
say 'hi there'
... more code ...
end
end
end
By comparison the ooRexx version is terse and if one is aware of
short-circuiting it is clear,
concise and faster/easier to understand than nested control constructs.
(If beginners like my students can understand and employ short-circuting in
ooRexx, the
short-circuiting is not a difficult concept and easily memorized.)
> Very few C coders understand the difference between '&' and '&&', for
> example. They randomly use
> both until the compiler complains.
Well I used to teach C++ twenty or so years ago, and all teaching made sure
that students would be
aware of the differences between '&&', '&', '||', '|', etc.
The same is true for students learning Java (which took over a lot of C/++
constructs and syntax to
make it easy for C/C++ programmers to switch to Java programming instead and
immediately understand
most of the Java code) who *must* be aware of the difference among '&&', '&',
'||', '|', etc.
And yes, I concur that all these operators can be distracting, just looking up
the Wikipedia article
on C/C++ operators gives an idea how difficult teaching to beginners may be:
<https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B> (one of my favored
ones there is the
"<=>" operator). For completeness here a pointer to the Java operators:
<https://en.wikipedia.org/wiki/Java_syntax#Operators>.
> In short: if the programmer wanted to 'save time' with a short-circuit then
> it would be better if
> they learned to make their code simpler and more readable. If they wanted to
> do a second test
> only if the first succeeded, they can always write that explicitly. And
> anyone who later reads
> that code will thank them for it.
Well if the problem to solve is simple, I agree.
Once one has to tackle more complex situations with chains of
conjunctions/disjunctions it starts to
make sense to allow short-circuiting them to allow the code to remain simple,
concise and readable
(and execution more efficient).
> That's why Rexx was designed to be (and hopefully still is): a language that
> is understandable --
> and, more importunately, usable -- to most people.
This is undisputed and a great strength of Rexx.
But, ooRexx is not Rexx, it is much more!
ooRexx is a language that started out with Rexx and able to run classic Rexx
programs to this day,
but has added so many new, advanced and "God-sent" features that Rexx simply
does not have like the
notion (from Smalltalk) that "everything is an object" (something that today's
programmers have no
conceptual problem with), that one sends "messages to objects" which then look
for methods by the
same name and run them on behalf of the programmer, which is a great
abstraction/simplification that
makes it incredibly easy to learn the language, but also to interact with
Windows (MS Office etc.)
or with .Net/CLR or with Java or with C++ objects as if they all were simple
ooRexx objects! Classic
Rexx coders may not be aware of the importance of the conceptual
simplifications a "message-based"
language allows for, but it is one of the most important secrets of ooRexx for
making interacting
with class libraries and objects so easy and straight-forward!
---
Teaching twice a year pure business administration students who start out with
no programming skills
and after a four month weekly 4-hour introductory lecture having them take
advantage of all of
Windows and all of Java by sending Windows and Java objects plain and simple
ooRexx messages is
something that has not been successfully done with any other language that I am
aware of. Nowhere.
As such ooRexx is probably one of the most efficient, but also cheapest
programming languages to
learn and one that allows to efficiently create programs from little control
scripts, macros to
fully developed professional applications.
---
But this is an ongoing challenge for ooRexx (not for Rexx):
in order to allow to add new features (like allowing short-circuiting
disjunctions) to ooRexx,
sometimes a new syntax is needed, sometimes the usage of operators may come
to mind to keep
everything simple.
So the challenge then is to still keep the ooRexx language small, easy to
read, to memorize and
to maintain. Maybe using operators with semantics they carry already in
Rexx/ooRexx may help to
keep the language as simple as possible.
---rony
>
> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
> *Sent:* 05 September 2020 19:30
> *To:* oorexx-devel@lists.sourceforge.net
> *Subject:* Re: [Oorexx-devel] Short cutting logical operators
>
> On 04.09.2020 15:51, Mike Cowlishaw wrote:
>> I think you all know my opinion on weird notations in languages that are
>> only known and used
>> by a few 'elite' programmers -- yet are all-too-easily misunderstood by
>> less-practiced (or
>> simply less-able or infrequent) programmers...
>
> Yes, I think everyone concurs.
>
> However, the question still remains, if one wishes to add the ability to
> short-circuit to Rexx
> (like programmers coming from C/++/#, Java etc are accustomed to and
> surprised that this
> concept is not available in Rexx), how to do it.
>
> Currently Rick added the comma as a delimiter indicating a short-circuit
> using and
> concatenations. Then, if short-circuiting or concatenations should be
> supported, how to allow
> them to be expressed in a "Rexxish" manner that is not only known to a
> few 'elite'
> programmers, but anyone who comes from C/++/# or Java?
>
> ---rony
>
>
>>
>>
>> ----------------------------------------------------------------------------------------------------
>> *From:* Erich Steinböck [mailto:erich.steinbo...@gmail.com]
>> *Sent:* 04 September 2020 14:22
>> *To:* Open Object Rexx Developer Mailing List
>> *Subject:* Re: [Oorexx-devel] Short cutting logical operators
>>
>> You're right.
>> I've often wondered whether a method call really *must* evaluate all
>> its arguments upfront.
>> What about lazy evaluation? Only evaluate an argument when it is
>> actually required, i. e.
>> accessed for the first time?
>>
>> On Fri, Sep 4, 2020 at 3:17 PM Rick McGuire <object.r...@gmail.com
>> <mailto:object.r...@gmail.com>> wrote:
>>
>> Hmmm, I found an awkward bit with this proposal. For the
>> operators, these are all
>> transformed into method calls under the cover, so "a | b" gets
>> executed as
>> "a~'|'(b)", where the object on the left hand side does the
>> evaluation of the
>> condition. This allows any class to override the '|' and '&'.
>> With the overrides, the
>> evaluation needs to be handled directly by the operator code
>> because there's no way
>> to delay evaluation of a method argument, and it would be very
>> difficult to allow
>> something like that to exist. I'm not sure I'm comfortable with
>> '*|' and '*&' be
>> special cases as operators.
>>
>> Rick
>>
>> On Fri, Sep 4, 2020 at 9:03 AM Rick McGuire
>> <object.r...@gmail.com
>> <mailto:object.r...@gmail.com>> wrote:
>>
>> There's been a bit of a discussion about the short-cutting
>> conditional lists
>> implemented by IF, WHEN, et al. I find that construct very
>> useful, but as the
>> discussion on the list has revealed, it has its limitations.
>>
>> It would actually be fairly trivial to implement AND and OR
>> operators that can do
>> short-cut evaluation. Of course, this is not possible for
>> XOR, which always
>> requires both values. The real questions are 1) should it be
>> done and 2) what
>> should the operator be. I've been tentatively using *& and
>> *| in my thinking
>> about this, but there are certainly other possibilities.
>>
>> Rick
>>
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
