dxf <dxforth@gmail.com> writes:

A program that relies on an 'ambiguous condition' can hardly be portable.

That depends on the ambiguous condition. In particular, looking at <https://forth-standard.org/standard/doc#subsection.4.1.2>, I see

|producing a result out of range, e.g., multiplication (using *)
|results in a value too big to be represented by a single-cell integer |(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
|FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);

Certainly for * every system with a given cell size produces the same
result. This has led to the result of * overflow being standardized
in the next release <http://www.forth200x.org/twos-complement.html>.
It's interesting that this ambiguous condition does not mention +, -,
or it's variants.

Bottom line: In some cases there is common practice even if it has not
been standardized.

I don't think that the documentation in 4.1.2 is useful to find such
common practice, though.

If ANS wants to claim documenting it will make it 'standard' that's their >business and yours if you choose to buy into it.

I don't know who this ANS is and why he/she would "want to claim" such
a thing, and why anybody should care about such a supposed urge, if
he/she does not actually make such a claim.

In any case, Forth-94 and Forth-2012 require standard systems to
document some ambiguous conditions. As you point out, that certainly
does not help in writing portable programs.

If the behaviour is considered a feature by the Forth system
implementor, the behaviour will certainly be documented without such a requirement. If it is not a feature, what use should a programmer
have from the documentation?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> writes:

On 9/12/2023 6:18 pm, Anton Ertl wrote:

That depends on the ambiguous condition. In particular, looking at
<https://forth-standard.org/standard/doc#subsection.4.1.2>, I see

|producing a result out of range, e.g., multiplication (using *)
|results in a value too big to be represented by a single-cell integer
|(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
|FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);

Certainly for * every system with a given cell size produces the same
result. This has led to the result of * overflow being standardized
in the next release <http://www.forth200x.org/twos-complement.html>.
It's interesting that this ambiguous condition does not mention +, -,
or it's variants.

Bottom line: In some cases there is common practice even if it has not
been standardized.

I don't think that the documentation in 4.1.2 is useful to find such
common practice, though.

It was 'ambiguous' because the result was mathematically incorrect.

Where do I find the documentation on the reasons for this ambiguous
condition that your claim is based on?

I don't have such documentation, so I can only guess. And my guess is
that it's because Forth-94 allowed systems to choose among three
different representations of negative numbers: 2's-complement,
1s-complement, sign-magnitude. And these representations result in
different behaviour on overflow, so the easiest way was to declare
this to be an ambiguous condition.

In any case, it does not matter whether you consider the result to be "mathematically incorrect", modulo arithmetic produces results that
are useful for some applications (e.g., for hash functions), so given
that it is common practice, it is a good idea to standardize it.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)