+1e1000
On 9/5/2020 3:48 PM, Mike Cowlishaw wrote:
Rony, this was added to NetRexx back in the 1990s. ooRexx does it
differently, for whatever reason. 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. Very few C coders
understand the difference between '&' and '&&', for example. They
randomly use both until the compiler complains.
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.
That's why Rexx was designed to be (and hopefully still is): a
language that is understandable -- and, more importunately, usable
-- to most people.
Mike
----------------------------------------------------------------------
*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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
