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

Re: SRFI-10 syntax vs. #nA syntax



Bradd W. Szonye wrote:
>> Vector and array literals are extremely important in some application
>> areas, especially graphics programming.

Matthias Radestock wrote:
> 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.

That's not a fact, as Bear and I have both pointed out. Bear's list of
examples included many arrays that typically appear in programs as
literals. Bear even gave a specific example (graphics software often
includes many literal transformation matrices) in an attempt to clear up
the misunderstanding.

> Nobody in this discussion has objected to the former; all the
> arguments have been about the latter two.

Yes, because some folks use literal arrays a lot, and therefore want a
terse syntax for it, but Taylor keeps objecting to it. Furthermore, he
keeps insisting on an unacceptable alternative (SRFI 10 syntax, which is
verbose, ugly, hard to type, and incompatible with quasiquotation). It'd
be better to omit array literals entirely than to use SRFI 10 syntax.

I disagree with Taylor's specific recommendation (SRFI 10), his general
argument (terse array literals aren't important), and his assessment of
the argument (it looks to me like Taylor is confused, not Bear).

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

1. Terseness: I don't mind a more verbose syntax for homogeneous arrays,
   but I strongly believe that heterogeneous arrays should have a syntax
   as convenient as that of lists and vectors. In particular, if it's
   easier to type a vector of vectors than it is to write a simple
   heterogeneous array literal, the syntax has failed.

2. Serialization: Yeah, this isn't too important, and it should be close
   enough to read/write the list decomposition of an array instead (so
   long as there are convenient functions to translate between arrays
   and their decompositions).

3. Immutability: Not an issue for me.

Really, it's the terseness I care about most. I write "toy" programs
more than anything else -- I'm always writing little scripts and tools
to solve specific problems -- and toy programs use a lot of literals. If
I need a 3x3 matrix, I don't want to type a bunch of junk like

    (array 2 vector '((11 12 13) (21 22 23) (31 32 33)))

when

    '#(#(11 12 13) #(21 22 23) #(31 32 33))

does the same job quicker and more clearly. My suggestion,

    '#3x3((11 12 13) (21 22 23) (31 32 33))

is also quick, clear, and has some precedent in PLT Scheme syntax. Note
that it's more expressive than the vector-of-vectors at the same cost in
characters and mental complexity, which is good. A terse syntax like
that has some chance of actually getting used. With the array-2-vector
stuff, people aren't going to use arrays on toy programs. Vectors of
vectors are easier. Heck, using /Perl/ would be neater, and Perl is
lousy at multi-dimensional arrays.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd