1. Forum
  2. Usenet
  3. COMP.LANG.FORTH

  • Re: Documenting system-specific behavior

    From Anton Ertl@21:1/5 to dxf on Sat Dec 9 07:18:24 2023
    dxf <[email protected]> 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)
  • From Anton Ertl@21:1/5 to dxf on Sat Dec 9 11:24:32 2023
    dxf <[email protected]> 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)