| Date: Mon, 3 Jan 2005 15:22:48 -0800 (PST)
 | From: Taylor Campbell <xxxxxx@autodrip.bloodandcoffee.net>
 |
 | 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.

If it is not a compromise, then whose plan is it?  My proposal
(implemented in SCM) used SRFI-4 abbreviations.  Per Bothner wants
FLOAT, -U, and -S for names.  Bear wants square brackets.

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

You did a good job, moving us toward Scheme vocabulary and away from
bastard C types.

 | 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 heterogeneous arrays are compatible with Common-Lisp:

  #0A foo
  #1A (foo bar)
  #2A ((foo bar) (bar foo))

Since SLIB does not specify read-syntax, there is no read-syntax
incompatibility between SLIB and SRFI-58.  As for the new prototype
names, they are directly provided by the 13 definitions in SRFI-58:

  (define A:complex-64 ac64)
  (define A:complex-32 ac32)
  (define A:real-64    ar64)
  (define A:real-32    ar32)
  (define A:integer-64 as64)
  (define A:integer-32 as32)
  (define A:integer-16 as16)
  (define A:integer-8  as8)
  (define A:integer+64 au64)
  (define A:integer+32 au32)
  (define A:integer+16 au16)
  (define A:integer+8  au8)
  (define A:boolean    at1)

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

No new transparent type has been added to Scheme reports in over 20
years.  Having observed the process of creating R4RS and R5RS, I
learned that proposals which aren't completely and thoroughly thought
out will not be adopted; there is a huge bias toward inertia.

Here are the procedures and syntax of Scheme's three transparent
aggregate types:

	list?		vector?		string?
	list		vector		string
	length		vector-length	string-length
	list-ref	vector-ref	string-ref
	append				string-append
			make-vector	make-string
			vector->list	string->list
			list->vector	list->string
			vector-set!	string-set!
			vector-fill!	string-fill!
	(...)		#(...)		"..."

Scheme numbers also come with predicates, conversion procedures, and
syntax.  Would the R6RS-editors adopt arrays without a
read/write-invariant syntax?  It doesn't look likely.

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

My array procedure missive may have crossed in the emails.  It
provides a trivial extension to SRFI-10 syntax, and an even more
useful form (supporting UNQUOTE) as a procedure.

 -- Function: array rank protothunk contents

     RANK must be a nonnegative integer.  PROTOTHUNK must be a
     procedure of no arguments returning an array.  CONTENTS must be a
     RANK-deep nesting of lists or vectors.  For RANK = 0, CONTENTS
     can be any object.

     `array' creates and returns an array of the type returned by
     calling PROTOTHUNK with no arguments.  The returned array has
     RANK dimensions; and elements taken from CONTENTS in one-to-one
     correspondence, the innermost lists or vectors corresponding to
     the rows (the last index).

Calls to `array' look very much like SRFI-10 read-syntax:

  (define ident2 (array 2 A:real-32 '((1.0 0.0) (0.0 1.0))))
  (define ident2 #,(array 2 A:real-32 ((1.0 0.0) (0.0 1.0))))

 | >   Literal arrays would not be used often enough to warrant a "#"
 | >   syntax.

Even if you have more experience writing Scheme code than I do, your
opinion of the usefulness of literal arrays has no bearing on my or
other's experience.  I have been using arrays in Scheme for years; I
want array syntax.

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

Whether it is necessary or not is a matter of opinion.

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

R2RS?  Wow, maybe you do have more experience!  But the rrrs-authors
have spoken; the reports clearly favor read/write invariant notations.