Aubrey Jaffer wrote:
>> The current state of SRFI-58 is a compromise.  It is likely that none
>> of us are completely happy with the choices (I prefer shorter
>> prefixes), but SRFI-58 tries to balance the major concerns expressed
>> by the participants.

Taylor Campbell wrote:
> This is hardly a compromise at all.  All that has been done is change
> a minor point I mentioned in passing (which I am thankful for you
> having fixed), namely the naming scheme of array element
> representations ...

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.

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.

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.

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

> 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. I don't like the proposed syntax for homogeneous arrays, nor
do I like the use of rank instead of shape in the array token. However,
the basic idea is sound.

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

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

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

Based on this and the following remark ...

> (For what it's worth, by the way, I didn't think it was a good idea to
> introduce the literal vector syntax back in R2RS.)

... I suspect that you're not part of the target audience for this SRFI.
Vector and array literals are extremely important in some application
areas, especially graphics programming.
--
Bradd W. Szonye
http://www.szonye.com/bradd