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.

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.

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

> Unless you can point to a very good justification of
> the notation in Common Lisp, this assertion is rather useless.  This
> could, after all, be carried out to the extreme, in which case I might
> ask: why aren't you using Common Lisp?

Actually, I'm more of a Scheme implementor than a Scheme user.
There are things I prefer in Common Lisp, and things I prefer
in Scheme.  The former includes the array/sequence model, and
the concept (but not the syntax) of optional type declarations.

> No: type specifiers are a fundamentally different thing from what I've
> been calling somewhat misleadingly 'array element type specifiers.'
> What arrays require is a _representation_ specifier: it needs to know
> what each element will represent & how much space is needed to do so.
> Type specifiers are an entirely different matter altogether.

They're not that different at all.  Type spcifiers in Kawa also
affect representation.  For example in Kawa:
   (let ((i :: <int> init-expr)) ...)
The variable i is represented as an immediate (unboxed) 32-bit integer.
In:
   (let ((j :: <integer> init-expr)) ...)
The variable j is an object reference (boxed), but it is required to
be a reference to a gnu.math.IntNum object.  This is not just a
specification, since it goes all the way down to the bytecode verifier.

> A comprehensive static type system, with parametric polymorphism, a type
> lattice, recursive union types, &c., won't help with arrays, and any
> static type system that is not as comprehensive as that is insufficient
> to adequately describe Scheme terms.

I'm not proposing a "comprehensive static type system", but optional
static typing has quite useful, if nothing else as documentation
checked by compiler and/or run-time.  I don't like some aspects of
the Common Lisp type declaration facility, but I think it's a mistake
for any serious programming language not have them.  Type specifiers
don't have to be "complete" to be useful.

> A good optional static type ... is wholly orthogonal to
> discussion of arrays: representations and types should not be conflated
> in this discussion,

Types (in some cases) imply representation.

I'm not suggesting type specifiers, at least not for this srfi.  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.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/