On Tue, 4 Jan 2005, Bradd W. Szonye wrote:

> For what it's worth, I don't like the new names. I agree with Per
> Bothner that using "integer+<bits>" to mean "unsigned fixnum" is
> counterintuitive. Also, there's very little visual distinction between
> that and "integer-<bits>," which breaks an important guideline for
> identifier naming. The alternate suggestion of "integer-<bits>+" is no
> better.

I don't disagree here; my original beef was just with the excessive
abbreviation.  My suggestion of INTEGER<bits>+ was only a very minor
one that I'm not set on: it was only a suggestion as a better way to
use + to indicate the sign, as opposed to what the current draft uses
(the INTEGER{+,-}<bits> device).  I have no objections to using some
other convention for indicating an implicit positive sign (/absence of
sign), as long as it is not unreadably obscure like AU32.

> Furthermore, the "long" names don't correlate well to the array
> prototyping functions defined in SRFI 47. While AC32 and :complex-32
> have a reasonable mnemonic connection, the same pattern doesn't apply to
> AU32 and :integer+32 or to AT1 and :boolean.

I did mention when I first suggested longer names that I thought SRFI
47's naming scheme was awful but also that it may not be a good idea to
break consistency with it.  (I have no idea where AT1 came from,
though, which is why I suggested BOOLEAN.)

> Finally, I dislike the mixture of math and hardware terminology. If the
> goal of heterogeneous arrays is to match the hardware, use hardware-
> speak consistently. The floating-point arrays are especially bad: If you
> mean "IEEE 754 single-precision floating-point number," then call it
> that (or some reasonable abbreviation, like "single" or even "s").
> Calling it a "real-32" is less descriptive.

This sounds quite reasonable.  I support this naming change (and the
other suggestions for changes in your more extensive discussion of the
floating-point-related names), though I have nothing more to say on the
matter.  (I suggested REAL-32 only because it was already called AR32
or something.)

> > [Now] the syntax is still as complicated -- perhaps even slightly more
> > so --, not possible to implement based on SRFI 10, and even
> > incompatible with Common Lisp & SLIB!
>
> I don't get this. It looks like a purely cosmetic change to me, no more
> incompatible with other formats than the original was.

The only matter at hand _is_ cosmetics: that's what the whole debate of
syntax is!  The original format, however, was, I believe, compatible
with both Common Lisp & SLIB, for the subsets where there was semantic
intersection (with heterogeneous arrays).

> > This [elided] is an argument that has been repeatedly cited in the
> > totally wrong context.  This is an argument for having arrays at all.
> > What is in question here is the _syntax_ for arrays.  SRFI 10 is for
> > consistent & simple extension of Scheme's syntax, which is
> > fundamentally centred around lists & symbols, but which has nothing to
> > do with arrays at all.
>
> You say that like it's a good thing. I disagree; like Bear and Aubrey, I
> believe that the lack of a terse array syntax is a weakness in the
> language.

This claim has not been defended.  What is important is not the way one
can write a literal array but the ease with which one can _operate_ on
arrays.  As I have suggested already, if you want this to be improved,
work on a comprehensive array library; it is unrelated to the
complication of Scheme's syntax.

> ...nor do I like the use of rank instead of shape in the array token.

Using shape instead of rank deserves a different discussion: it might
be better to bring it up in a new thread, so that it doesn't get bogged
down by the discussion of the base syntax.  I think it would probably
be a good idea, too, though I, again, don't passionately care one way,
and I also haven't thought it through very carefully yet.

> > I do not deny that arrays are a very important thing to have.  They
> > should not, however, completely unnecessarily complicate an otherwise
> > almost unmarred syntax that is one of the hallmarks of Scheme.
>
> I think SRFI 10 itself unnecessarily complicates the language. The
> syntax is cumbersome and verbose, and the specification has some bugs.

Cumbersome & verbose as compared to what equally general syntactic
extension, and what bugs do you refer to aside from what you allege to
be problems with how SRFI 10 relates to quasiquotation?

> Worse, it does not (as written) permit quasiquotation, which is
> important for describing arrays with fixed shape but variable elements.
> The current version of SRFI 58 doesn't describe quasiquotation either,
> but at least it's possible to extend it that way. SRFI 10 seems to
> forbid quasiquotation entirely. (See my comments on the
> post-finalization mailing list for SRFI 10.)

The facts you discovered concerning the allowed placement of SRFI 10
#,(...) forms are correct.  The conclusions drawn are not.  It does not
always make sense that quasiquotation should apply to all SRFI 10
constructors, such as homogeneous arrays, which _can't_ hold list
structures (the structures that, for example, the #\, syntax expands
to, (UNQUOTE ...)).  On the other hand, there is nothing that SRFI 10
instated to _prevent_ new SRFIs from defining constructor tags such
that the surrounding #,(...) may be used within a quasiquotation.  The
more significant issue, however, is whether or not the unquoting within
the #,(...) will be processed by the macro transformer for QUASIQUOTE,
which must be extended for every new data type given a new #,(...) tag
that one wishes to allow to be used as lists & vectors may be in
quasiquotations.

Note, by the way, that your `,'#,(...) example -- (QUASIQUOTE (UNQUOTE
(QUOTE #,(...)))) -- would not have the same effect as simply `#,(...),
even assuming all SRFI 10 data were allowed in quasiquotations.  The
SRFI 10 datum is simply embedded in a quote; it is the same as writing
'#,(...) -- (QUOTE #,(...)) -- in the first place.  This is consistent
with the rest of SRFI 10, which does not specify how the #,(...) form
operates with quasiquotation.

> > Arrays are fundamental to computing, yes, but not fundamental to
> > Scheme's syntax.
>
> The SRFI is no good unless the array syntax is usable, and SRFI 10 isn't
> good enough, technically or aesthetically.

This has not been substantiated technically, and it is worthless to
repeatedly argue of aesthetics when neither side has any clear
advantage.

> >> [snipped long list of applications for arrays]
>
> > I have responded to this already: these are all uses for arrays, but
> > they have very little to do with _hand-written_ literal arrays ....
>
> I don't know how you came to this conclusion, and I don't know why
> you're repeating this false claim even after Bear's extended example
> (literal matrices for coordinate transformations in graphics
> programming).

I came to this conclusion after bear mentioned such programs _dumping_
_S-expressions_.  The part of the sentence that you deleted had
significance as well: '...and a lot of them will involve large data
sets that will completely dwarf the size of the initial few characters
of the literal array.'  Furthermore, I showed that bear's example is
_hardly_ more verbose or column-consuming than his original vectors;
it would not be much different with the current proposed array syntax,
either.  And this is for a fairly _small_ matrix.

> Vector and array literals are extremely important in some application
> areas, especially graphics programming.

I don't deny that.  I deny, however, that it is worthwhile to
unnecessarily complicate Scheme's syntax just so that it is made almost
the _tiniest_ bit more convenient to write a literal array.