| Date: Fri, 31 Dec 2004 11:07:26 -0800
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | xxxxxx@autodrip.bloodandcoffee.net wrote:
 |
 | > On Thu, 30 Dec 2004, Per Bothner wrote:
 | >
 | >>Array syntax should be compatible with Common Lisp's notation.
 | >>Anything else requires a *really* strong justification.
 | >
 | > Why doesn't Common Lisp's notation require just as strong of a
 | > justification?
 |
 | Scheme's syntax is in general very close to Common Lisp's.  This
 | includes the notation for vectors.  The Common Lisp vector and
 | array notations are related, which makes sense since a vector is a
 | special case of an array.  The Scheme vector notation is the same
 | as the Common Lisp vector notation.  Having a completely different
 | array notation would reduce interoperability and skill
 | transferability for no good reason.

Yes.

 | I'm also concerned about stylistic compatibility within Scheme
 | itself, regardless of Common Lisp.  Requiring SRFI-10 notation for
 | arrays but not for vectors, is really ugly and makes arrays into
 | second-class constructs, which is unfortunate given that vectors
 | are just a special case of arrays.

Amen!

 | Some Scheme implementations may already support Common Lisp's #A syntax.
 | (I thought Kawa did, but I guess I never got around to implementing it.)

SCM does.  Guile does #<n>((...)); they lost the A.

 | ...
 | What I am requesting is that "array type specifiers" should be
 | written to use "element type names", not "array type names", and
 | that element type names should be identifiers that would make sense
 | it somebody *does* do type specifiers.  I.e. instead of "aint32" or
 | "as32" use "int32" or (for example) "array:int32" (depending on
 | context).
 |
 | Some Scheme implementations *do* support type specifiers, and of
 | those specifiers some are also representation specifiers; please
 | don't invent an array type syntax incompatible with type specifiers
 | for declarations.

Are there type specifiers in common between Scheme implementations?
Which implementations?

For Scheme type-specifiers, most of what Google found are for foreign
datatypes.  The treatment of signed versus unsigned involves either
the word "unsigned" and its absence; or the letters S and U.

Having complex arrays and bit-arrays, SRFI-47 and SRFI-58 were not
motivated by foreign-language interfaces.  I will replace the foreign
numerical terminology.

Here is a plan which, using the delimiter you suggested, indicates
signed vs. unsigned with - versus +:

exactness       element type                    prefix
=========       ============                    ======
                any (vector)                    #nA
inexact         64.bit + 64.bit complex         #nA:complex-64
inexact         32.bit + 32.bit complex         #nA:complex-32
inexact         64.bit real                     #nA:real-64
inexact         32.bit real                     #nA:real-32
exact           64.bit integer                  #nA:integer-64
exact           32.bit integer                  #nA:integer-32
exact           16.bit integer                  #nA:integer-16
exact           8.bit integer                   #nA:integer-8
exact           64.bit nonnegative integer      #nA:integer+64
exact           32.bit nonnegative integer      #nA:integer+32
exact           16.bit nonnegative integer      #nA:integer+16
exact           8.bit nonnegative integer       #nA:integer+8
                char (string)                   #nA:char
                boolean (bit-vector)            #nA:boolean

Another possibility is to use the word "natural" for nonnegative
integers:

exact           64.bit natural-number           #nA:natural-64
exact           32.bit natural-number           #nA:natural-32
exact           16.bit natural-number           #nA:natural-16
exact           8.bit natural-number            #nA:natural-8