Re: 0 SET-ORDER why?

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?

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.
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.

Which was just as well as there was
a use for it the TC apparently overlooked.

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