[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
External syntax of homogeneous vectors
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.