Thanks for all the replies about single-flonum uses!
I've pushed the change to try out disabling single-flonum literals as
Note that this change doesn't remove the concept of single-flonum
values from the language. It just removes single-flonum literals from
`#lang racket` and other languages that use the S-expression reader.
If you have a program with a single-flonum literal expression in it,
then you can convert to a use of `real->signle-flonum`:
On a Racket variant that supports single-flonum values (like the
current version of Racket), the compiler will constant-fold that
expression to a single-flonum value, so the compiled code is the same
as writing a single-flonum literal. On a Racket variant that does
support single-flonum values, however, that expression will raise an
Here's an example in `degrees->radians` in `racket/math`:
The call to `real->single-flonum` is in a `cond` clause that is guarded
with a `single-flonum?` test. Obviously, that guard will succeed only
in a Racket variant that supports single-flonum values, so we don't
need to worry about the `real->single-flonum` operation failing.
For cases where there's no natural `single-flonum?` guard, a new
`single-flonum-available?` function reports whether single-flonum
values are supported. It currently produces #t in the current version
of Racket and #f in Racket CS.
Finally, you can set the new `read-single-flonum` parameter to #t to
restore single-flonum parsing at the level of `read`. You can set
`read-single-flonum` to #t on Racket variant that does not support
single-flonum values, but `read` will raise an exception if it
encounters a single-flonum number.
Although we could make a language or a language constructor that
enables single-flonum literals by setting `real-single-flonum`, I think
we should try discouraging that, for now. Admittedly, I used a little
reader to do that in the test suite for the core single-flonum
operations, but that feels like a special case.