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