Well I promised too much: CRX gives an error but rounds 18 to 20 in the error message.
still i think 2 is also valid René. > On 10 Nov 2020, at 10:36, René Jansen <rvjan...@xs4all.nl> wrote: > > 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
