Chip, I agree that staying away from sharp objects is good, and the discussion is mostly academic.
But here some other arguments to consider: 1) this can be distilled down to when it is necessary to evaluate an expression. If the expression is a number, one might argue it has been evaluated already, and does not need further evaluation under the numeric digits constraints. When it is not a number, it should be evaluated like any other expression. 2) it appears - I have been told - that CRX (of which I do not have a running version), does evaluate the numeric argument under the current settings and comes up (for 18) with 2E+1, so 2. While just as astonishing (well, maybe a bit more), this is even more PLE than ooRexx. With this, I will now be silent on this subject until the next ARB meeting. René. > On 10 Nov 2020, at 00:34, Chip Davis <c...@aresti.com> wrote: > > We must be careful we don't cut ourselves on such a sharp edge-case. The > salient arguments boil down to: > - The Principle of Least Astonishment argues for modifying ooRexx to match > the behavior of other Rexx'es. > - The Policy of Least Exceptions argues that ooRexx has the right rule. > > The purist in me contends that the ooRexx behavior is the correct one, and we > should simply update the errortext: "DIGITS value must be a positive whole > number expressible under the current setting of "NUMERIC DIGITS nn"; found > "dd". We could do that for ooRexx and NetRexx, but the likelihood of any IBM > Rexx processor following suit, is nil. > > There is a valid argument for making ooRexx consistent with all the other > Rexx'es out there, especially the huge installed base of IBM Rexx code. One > might hope that the number of ooRexx programs affected by this change could > be expressed in Numeric Digits 2, but who knows where (or how critical) that > code may be. This will also require documenting (and test-casing) this > exception to the current behavior. But it won't be the only place that the > design of Rexx has bent an ideal consistency to the reality of dealing with > humans. > > As big a fan of consistency as I am, I'm afraid I come down on the more > pragmatic PLA side of this issue, especially given the expected amount of > code affected. > > -Chip- > > > > _______________________________________________ > 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
