SRFI-10 syntax vs. #nA syntax Aubrey Jaffer (03 Jan 2005 05:23 UTC)
Re: SRFI-10 syntax vs. #nA syntax bear (03 Jan 2005 06:01 UTC)
Re: SRFI-10 syntax vs. #nA syntax Per Bothner (03 Jan 2005 06:37 UTC)
Re: SRFI-10 syntax vs. #nA syntax Aubrey Jaffer (03 Jan 2005 19:16 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (04 Jan 2005 22:28 UTC)
Re: SRFI-10 syntax vs. #nA syntax Per Bothner (04 Jan 2005 23:03 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 01:59 UTC)
Re: SRFI-10 syntax vs. #nA syntax Per Bothner (05 Jan 2005 02:13 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 03:08 UTC)
Re: SRFI-10 syntax vs. #nA syntax Per Bothner (05 Jan 2005 03:39 UTC)
Re: SRFI-10 syntax vs. #nA syntax Shiro Kawai (05 Jan 2005 02:39 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 02:48 UTC)
Re: SRFI-10 syntax vs. #nA syntax Taylor Campbell (03 Jan 2005 22:40 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 00:07 UTC)
Re: SRFI-10 syntax vs. #nA syntax Matthias Radestock (05 Jan 2005 01:25 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 02:41 UTC)
Re: SRFI-10 syntax vs. #nA syntax Taylor Campbell (05 Jan 2005 02:52 UTC)
Re: SRFI-10 syntax vs. #nA syntax Aubrey Jaffer (05 Jan 2005 03:25 UTC)
Re: SRFI-10 syntax vs. #nA syntax Bradd W. Szonye (05 Jan 2005 03:54 UTC)

Re: SRFI-10 syntax vs. #nA syntax Matthias Radestock 05 Jan 2005 01:25 UTC

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.