Re: 0 SET-ORDER why?

On 28/06/2024 7:51 pm, Ruvim wrote:

On 2024-06-27 07:19, dxf wrote:

On 26/06/2024 11:36 pm, Ruvim wrote:

On 2024-06-26 12:50, dxf wrote:

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

>
>
I think, in this case it's better to specify behavior than to declare an ambiguous condition.

>
No need to specify useless behaviours.

 
Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
 
BTW, do you think 0 PICK and 0 ROLL are useless?

No, because I've used them (at least in the case of PICK :)

u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

 
<https://forth-standard.org/standard/float/REPRESENT>
 
Of course, it's specified. It's specified for any u, including 0.
For example:
  "The character string shall consist of the u most significant digits"
 
If u is zero, the string must consist of zero digits.

Spec says:

   "u most significant digits of the significand"

Do you have a definition for '0 most significant digits of the significand' ?
I don't.  Nor did ANS provide one.

 
Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.
 
Probably, "represent" may return false at the top if u is zero.

No.  The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest.  Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

...
 
What is the problem anyway that the behavior is specified for
"0 SET-ORDER"?  What are bad consequences for systems or for users?

It would be a problem if there were no use for it.  It's not clear to me
that we're there yet.