(This is a personal opinion, and not necessarily representative of the
working group.)

1. I'm not sure. Requiring it makes it easier to simultaneously support
#!r6rs mode, but I'm not so sure of the utility.

    I think the exponent syntax is too limiting. A prefix (using `#`)
would be better, if such a thing is really necessary.

2. No. Most implementations only support one float format, and adding
new float formats to a runtime is probably quite a bit of work. It is
very unlikely that these would see use even if mandated.

    In addition, some “Large” Scheme implementations target languages
that do not define floats to always behave like this, such as C. Such
languages have been in wide use for numerical computing for a very long
time without mandating floating point formats like this proposal does.

    Although we will probably be stuck with binary64 for a long time,
the world has already used and then dropped a >64 bit format (x87 long
double), and there is not a lot of uptake for binary128. In addition,
there are quite a few 16 bit or lower floating point formats. R7RS-Large
should not risk crystallizing the wrong choice.

3. *If* they are mandated, then an implementation should raise an exception.

4. No, for similar reasons to (3).

5. No, but I see no reason to forbid them.

6. Yes. Hexadecimal floats make floating point code easier to read.

    (All examples here are binary64 aka double precision.)

    I'll give an example. I found an issue with some implementations of
SRFI 144's `flquotient` not returning the correctly rounded value. The
number that I used as a witness to this issue is 13510798882111490.0. In
hex float syntax, it is #x1.8000000000001p+53. The decimal number is
inscrutable, but the hex float number has an obvious peculiar feature
(the LSB of the mantissa and the exponent being the binary64 precision).
If I used the decimal version in the test suite, I would end up
explaining the information one automatically gets from the hex float
syntax in a lengthy comment about the issue.

    Beyond documenting pathological numbers, hex floats also have
pedagogical value. The average programmer understands base 16 but
doesn't understand floating point outside of “it represents decimal
numbers approximately.” With hex floats, you work in a base that works
well with binary floats, so some mysterious concepts become easier to
explain, like

    1. The next representable number (the next representable number
after #x1p0 is #x1.0000000000001p+0, the next representable number
before #x1p1 is #x1.fffffffffffffp+0, etc)

    2. Approximations to decimal numbers (0.1 is #x1.999999999999ap-4,
0.3 is #x1.3333333333333p-2: you can see they are not exactly
representable and become repeating hexadecimal expansions)

    Although R7RS-Large is not necessarily intended for “educational”
use, I believe this refers to programming language education. There is
no reason why an R7RS-Large implementation cannot be used in a class on
scientific computing or numerical analysis. Many of those classes use
languages like Matlab, Python, and C++, which are quite large!

-- Peter McGoron