This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
On Sun, 2 Jan 2005, Aubrey Jaffer wrote:
> The current state of SRFI-58 is a compromise. It is likely that none
> of us are completely happy with the choices (I prefer shorter
> prefixes), but SRFI-58 tries to balance the major concerns expressed
> by the participants.
This is hardly a compromise at all. All that has been done is change a
minor point I mentioned in passing (which I am thankful for you having
fixed), namely the naming scheme of array element representations; now
the syntax is still as complicated -- perhaps even slightly more so --,
not possible to implement based on SRFI 10, and even incompatible with
Common Lisp & SLIB!
> The use of SRFI-10 syntax for Arrays was discussed. The main
> arguments in favor of SRFI-10 were:
>
> SRFI-10 is for Scheme extensions, and thus appropriate for SRFI-47
> arrays if they are not incorporated into R6RS.
>
> My efforts are directed toward making multidimensional arrays
> part of R6RS. Multidimensional arrays have been an integral
> part of computing since before electronic computers. A supposed
> general-purpose computer language without multidimensional
> arrays is an oxymoron.
This is an argument that has been repeatedly cited in the totally wrong
context. This is an argument for having arrays at all. What is in
question here is the _syntax_ for arrays. SRFI 10 is for consistent &
simple extension of Scheme's syntax, which is fundamentally centred
around lists & symbols, but which has nothing to do with arrays at all.
I do not deny that arrays are a very important thing to have. They
should not, however, completely unnecessarily complicate an otherwise
almost unmarred syntax that is one of the hallmarks of Scheme. Arrays
are fundamental to computing, yes, but not fundamental to Scheme's
syntax.
> Literal arrays would not be used often enough to warrant a "#"
> syntax.
>
> Vector constants were thought useful enough that the "#(" syntax
> was appointed them. Many of the extant literal vectors
> (especially nested vectors) could be better expressed as arrays.
> Some literal nested lists would also be better suited to arrays.
> Bear@xxxxxxxxx gives some examples uses for literal arrays:
>
> [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, and a
lot of them will involve large data sets that will completely dwarf the
size of the initial few characters of the literal array. I have also
shown that literal arrays with my proposed syntax do not require many
more columns that bear finds so precious.
> The proposed "#nA" syntax consumes too much of the precious "#"
> name-space.
>
> The claim is that SRFI-58 would consume ten characters (the ten
> decimal digits), far more than the single "(" used for vectors.
>
> But this accounting is disingenuous. It is highly unlikely that
> a one digit "#" code, say "#5" would be registered without
> including the other digits. If we consider "#" followed by
> digits to be a numeric argument to the character following, then
> only one letter, "A", worth of name-space has been allocated.
> "#nnn" followed by the letters B-Z and punctuation are all
> available.
This, too, complicates the syntax unnecessarily. (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.) Read-time constructors that require
numeric arguments can accept them just as procedures & macros do: as
arguments in a list form, like #,(ARRAY <rank> ...). There is no good
reason to complicate the syntax as you suggest.