Marc Feeley writes:

 > John Stone <xxxxxx@cs.rice.edu> proposed to replace this with the
 > syntax #r32(...), with "r" standing for real.  To me this would be
 > inconsistent with the number classification in Scheme because exact
 > integers are classified as "reals", so a u8vector is just as much a
 > "real" vector as a f32vector.  The distinction between them is that
 > one contains exact real integers and the other inexact reals.
 > The name "float" is much more appropriate.

        Well, I understand now why #r for `real' isn't appropriate, so I'll
propose #r -- or, if that's too misleading, #j -- for `floating-point
representation of inexact real' instead.  What I really care about is
avoiding the overloading of #f.

 > To me the real problem with #f32(...) rests in the lexical syntax in
 > the Scheme standard and in the interpretation of that specification by
 > most implementors.  Why should #x32 and #d32 be parsed as one token
 > but #f32 as 2 tokens?

        Because #x and #d would have no separate significance as tokens,
whereas #f already has a denotation on its own.

 > If you think the lexical syntax
 > specification clearly states that #f32 should parse as 2 tokens then
 > you must also agree that #\space32 should parse as 2 tokens (but all
 > of the implementations of Scheme I tried give a syntax error because
 > they try to parse this as a single token, and the name "space32" is
 > not a valid character name).

        MzScheme parses it as two tokens.  It's too bad if a lot of other
implementations get this wrong, but it does seem to me that the way
to parse an R5RS character literal is to look, after mesh-backslash, for
something that is string-ci= either to "space" or to "newline", and failing
that simply to take the next character.  One does not need an explicit
delimiter in either of these cases.