[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-10 syntax vs. #nA syntax



Bradd W. Szonye wrote:

Taylor Campbell wrote:
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.

Taylor has tried to draw attention to the fact that people keep confusing the utility of an array data type with the utility of a literal array syntax, and the utility of an *extremely concise* literal array syntax. Nobody in this discussion has objected to the former; all the arguments have been about the latter two.

To re-focus the discussion, let us take an example from a recent post by Aubrey, in which he proposed an array constructor that takes the array contents as lists:

  (array 2 A:real-32 '((1.0 0.0) (0.0 1.0))))

This does not use array literals, is concise and works with quasiquotation and macros. Leaving aside issues of rank and naming, which the above shares with the literal syntax, what is wrong with it? I have some ideas what people might dislike:

1) It is not as concise as some special syntax. However, IMHO, syntactic conciseness is not one of the key features of Scheme - syntactic simplicity and clarity are, and on that account the above is, arguably, better than any literal syntax proposed so far.

2) It does not provide a way to serialize/deserialize arrays. However, the evidence from the Scheme standard suggests that Scheme's read/write and friends were primarily designed for processing programs as data, and not to (de)serialize arbitrary datums. For instance, one cannot serialize all symbols generated with string->symbol, circular lists and vectors, procedures, ports. In any case, s-expressions are hardly the pinnacle of external data representation, and most Scheme applications that I have worked on use a variety of non-s-expressions formats to store and communicate their data.

3) It does not provide a way to create immutable arrays. However, Schemes handling of immutable data is seriously underspecified anyway. There are no guarantees that literal data is really considered immutable and there is no way to construct immutable data containing datums computed at run-time. Furthermore, one could easily add an immutable array constructor to the array API.


Have I missed any concerns from this list?


Matthias.