This page is part of the web mail archives of SRFI 4 from before July 7th, 2015. The new archives for SRFI 4 contain all messages, not just those from before July 7th, 2015.
Marc Feeley writes: > John Stone <jstone@xxxxxxxxxxx> 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.