This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 are here. Eventually, the entire history will be moved there, including any new messages.
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