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

Re: #\a octothorpe syntax vs SRFI 10

bear wrote:
> I wanted an extremely terse syntax using the square brackets. It
> turned out that nobody else wanted it, based on aesthetic objections.

I too would like a terse vector/array syntax using square brackets. It's
a very common notation for vectors and matrices, so it's a natural
candidate for a Scheme external representation. However, too many Scheme
implementations already use brackets as a synonym for parentheses.
Bracket notation for vectors could've been a great language extension,
but I suspect that it's too late for that now.

Also, brackets have one major shortcoming (which the current SRFI 58
proposal shares): Since dimensions are inferred from the bracket
contents, there's no way to represent arrays with a 0 dimension. For
example, you can use SRFI 47 functions to create a 0x2x3 array:
(MAKE-ARRAY '#() 0 2 3). However, there's no "natural" external
representation for this array using brackets. Currently, SRFI 58 suffers
from the same problem: Its syntax specifies rank explicitly but infers
shape from the list decomposition. What should the Scheme writer use to
represent that array? Is it an error?

> You wanted an extremely verbose syntax using srfi-10. It turned out
> that nobody else wanted it, based on aesthetic objections.

I think #,(ARRAY ...) syntax is appropriate for some arrays. It would
permit a good, general notation for arbitrary arrays, based on the
MAKE-ARRAY function of SRFI 47.

    #,(ARRAY <prototype> (<dimensions>) (<element>...)opt)

For example (using the common "brackets = parens" syntax for clarity):

    #,(ARRAY #() (2 2) [[a b] [c d]])    ; 2x2 heterogeneous array
    #,(ARRAY (AS32) (2 2) [[1 2] [3 4]]) ; 2x2 array of 32-bit fixnums
    #,(ARRAY #() (0 2 3))                ; zero-dimension array

This allows the reader to use any SRFI 47 "prototype" function to
specify array types. Thus, if a Scheme implementation adds new array
types, they can simply add a new prototype generator. For example, an
implementation can extend both MAKE-ARRAY and the reader syntax to
support 36-bit integers simply by defining new "AS36" and "AU36"
prototype functions.

    (MAKE-ARRAY (AS36 0) 1 2) => #,(ARRAY (AS36) (1 2) [[0 0]])

I don't think this is appropriate for hand-written, heterogeneous
arrays, however. For those, I prefer something much terser. The proposed
syntax is almost good enough; however, I would rather it specify the
array /dimensions/ rather than rank. That's more consistent with
existing extensions, like PLT's #n(...) syntax for vectors.

Specifying the dimensions also permits a convenient shorthand for
repetitive arrays: If there aren't enough elements for a dimension,
simply repeat the last element. For example, #100(1) is shorthand for
#(1 1 1 1 ... 1) in MzScheme, and #100() is shorthand for #(0 0 ... 0).
A similar array syntax could use the analogous #A100x100() to get a very
large zero matrix.
Bradd W. Szonye