This page is part of the web mail archives of SRFI 4 from before July 7th, 2015. The new archives for SRFI 4 are here. Eventually, the entire history will be moved there, including any new messages.
In this message I will make a case for the external syntax proposed in SRFI-4, in particular the apparent nonconformance with Scheme implied by #f32(...) which most implementations of Scheme parse as the 3 objects #f, 32 and (...). 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. William D Clinger <will@xxxxxxxxxxx> proposed to add a "v" in the prefix as in #vf32(...), with "v" standing for vector. This could be extended to #vvf32((...) (...)...) for 2 dimensional arrays, etc. I don't think this is very elegant because it is implicit that this is a vector, so why add a redundant marker for this. For multidimensional homogeneous vector, nested lists could be used as in this 3 by 4 float vector: #f32((1.0 2.0 3.0 4.0) (1.0 2.0 3.0 4.0) (1.0 2.0 3.0 4.0)) The only problem with such a representation is that it is not possible to distinguish a 0 by 4 float vector from an empty one dimensional float vector, but a special notation could be used for this very unusual case, such as allowing a special suffix after an element to indicate a repetition factor (which is convenient for other reasons). For example: #f32(1.0 2.0 ^ 98 3.0) ; a 100 element one dimensional float vector ; containing one followed by 98 twos and then a three #f32((1.0 2.0 3.0 4.0) ^ 3) ; the 3 by 4 float vector shown above #f32((0.0 0.0 0.0 0.0) ^ 0) ; a 0 by 4 float vector #f32((0.0 ^ 4) ^ 0) ; the same 0 by 4 float vector #f32(() ^ 0) ; a 0 by 0 float vector #f32() ; this would be a 0 element one dimensional float vector 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? The Scheme standard is not clear about this (but all of the implementations of Scheme I tried do parse this as 2 tokens, except for Gambit). 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). So I maintain that #f32(...) is a perfectly reasonable syntax. I also think that the Scheme standard should be clarified to allow this (by requiring #f and #t as well as #\space and #\newline to be followed by a delimiter character such as a space or parenthesis). I believe this is consistent with Kent Dybvig's proposal at the Baltimore workshop which would require a delimiter after a character (so that #\123 would be an "error", allowing implementations of Scheme to give this a meaning, such as the character equal to (integer->char 123)). Marc