Questions to the public about floating-point lexical syntax and format Peter McGoron 28 Oct 2026 19:42 UTC

Hello,

Working Group 2 is soliciting information about floating point lexical
syntax and floating point formats. Feel free to forward these questions
to those you believe could answer these questions. We appreciate any input.

__________________________________________________________________

1. Requirement to parse exponent markers.

    The R5RS and R6RS required the parsing of the exponent markers s, f,
d, and l to represent "short," "single," "double," and "long" precision.
These were made optional in R7RS. These exponent markers allow the user
to write number constants in a particular floating point format, if it
is supported by the implementation.

    Should the R7RS-Large require readers to parse these as numbers? Or
should it keep support for them optional?

2. Format requirements.

    Previous Scheme reports have not required that the exponent markers
s, f, d, and l correspond to actual formats.

    Should the R7RS-Large fix the number representations that s, f, d,
and l correspond to? In particular, should they correspond to the
following IEEE formats:

    |  Exponent marker |  Corresponding format |
    |------------------|-----------------------|
    |        s         |      Binary16         |
    |        f         |      Binary32         |
    |        d         |      Binary64         |
    |        l         |      Binary128        |

    With this change, the exponent marker "e" would be at least as
precise as Binary64.

3. If an exponent marker corresponds to a representation, what should an
implementation do when it does not support the corresponding format?

4. Should we extend the list of standard exponent markers? In
particular, to add "b" to mean bfloat[1] and "w" for double-double.

[1]: https://en.wikipedia.org/wiki/Brain_floating-point_format

5. Is support for mixed-precision complex numbers useful?

6. Are hexadecimal floating-point constants useful as an addition to
R7RS-Large?

    See <https://srfi.schemers.org/srfi-270/srfi-270.html> for the
proposed syntax.

__________________________________________