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 <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.

William D Clinger <xxxxxx@ccs.neu.edu> 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