Re: #\a octothorpe syntax vs SRFI 10

[campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx]

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

> If you want to *extend* the Common Lisp syntax with a type
> specifier, that is ok.  But that should be done with type
> specifiers.  So don't use crypic abbreviations; use type
> names that can form the basis for optional type specifiers.

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.  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.  A good optional static type
system for Scheme is _far_ outside the scope of this SRFI or SRFI 47
(so no, I'm not going to bother defending my statement that any less
expressive type system is insufficient), and it is wholly orthogonal to
discussion of arrays: representations and types should not be conflated
in this discussion, and I probably ought to have been using a term
other than 'array element type.'

> I agree with the goals of srfi-58.  Unfortunately, it builds
> on srfi-47, which I don't care for.  I'd prefer:
>    (make-array <element-type-specifier> elements ..)
> where an <element-type-specifier> might be something
> like <int16>.

First class representation descriptors introduce a whole new can of
worms that I don't think is really worth opening in this discussion of
a SRFI about a literal array syntax.

>                Then we could add optional static typing:
> 
> (define i1 :: <int16> 1)   ;; or:
> (define (i2 :: <int16>) 2) ;; alternative syntax
> (make-array <int16> i1 i2)
> 
> Kawa implements part of this, mapping Scheme type specifiers
> to Java classes or primitive types.
> 
> We'd want an array type specifier too, perhaps <arrayN:ELEMENT-TYPE>:
> (define arr1 :: <array2:uint16> #2a:uint16((1 2) (3 4)))

I'm afraid that I might incite a flame war if I started to discuss the
huge complication of an otherwise fairly unmarred syntax that this
would introduce...