Re: 0 SET-ORDER why?

On 2024-06-28 16:19, dxf wrote:

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.

It's seems obvious to me: 0 digits means the empty string.

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

"the significand represented as a decimal fraction", so each digit is chosen from {0,1, ..., 9}.

Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

It's a problem of particular implementations.
The result is the empty string, and this is independent of how you round. Then you don't have to round at all.
It reminds me of the choice between lazy evaluation and eager evaluation.
If the lazy evaluation approach, if the result does not depend on a parameter in a certain case, then the parameter is not computed at all.
In the eager evaluation approach, computation of the result may never halt because computation of an *unneeded* parameter is never halt in a certain case.

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

Well, this case can be found useful.
But, in general, what's wrong if a consistent and expected behavior is specified for a case that is not used in real programs?
--
Ruvim