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

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

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

			      -=-=-=-=-

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 "#"
  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.
      xxxxxx@sonic.net 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 "#"
  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.

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