[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI-10 syntax vs. #nA syntax
Some email threads have continued after changes to SRFI-58 made them
moot, which I have thus far not responded to. The appended addition
to the Issues section (perhaps it should be in Rationale) addresses
what I think were the main arguments in favor of SRFI-10 vs. #nA
I know that I don't own all the best ideas, and have responded to and
incorporated ideas from all the major contributors to these
discussions. The current SRFI-58 bears little resemblance to my
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. I hope we can feel some pride in having
cooperatively forged an important piece of Scheme for the new
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.
Literal arrays would not be used often enough to warrant a "#"
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:
Data tables for character properties. color palettes.
Graphic sprites. Coordinate transformation matrices.
cellular automata substructures. Default Window coordinate
lists. Map data. Integrated-circuit diagrams. Alias
tables for character names. Parallel Records. Tuple
aggregates. Multi-Character tokens for protocol drivers.
Image data. Compiler transition tables. Tax rate tables.
Icons. Lists of countries, states, counties, and
municipalities. Bus routes. Airline schedules. Cellular
coverage areas. And the list goes on... Programs need to
be able to dump this information to file in S-expressions
and read it back.
The proposed "#nA" syntax consumes too much of the precious "#"
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
A choice must be made between SRFI-10 syntax and "#nA" syntax. I felt
the reasons in support of the "#nA" syntax given in the Rationale were