Re: #\a octothorpe syntax vs SRFI 10

[campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx]

On Fri, 31 Dec 2004, Per Bothner wrote:

> campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> 
> > 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.

Interoperability is impossible anyway.  How do you deal with Common
Lisp's package system?  However, arrays are arrays, regardless of how
you write them.  There is no significant difference in 'skills' between
Common Lisp arrays and SRFI 47 arrays with a #,(ARRAY ...) syntax.
Moreover, there _is_ a good reason for having a SRFI-10-bases syntax as
opposed to Common Lisp's #\a octothorpe reader syntax: to make Scheme's
syntax simpler & more consistent.  This is not just simply a nice thing
to have, but one of the hallmarks of Scheme in the first place.  It is
_not_ a good idea to complicate it totally unnecessarily, just to
retain a vague notion of compatibility with old, crufty Lisps.

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

I think it would be perfectly fine, except for backwards compatibility
problems, to flush the #(...) vector syntax in favour of a more general
array syntax.  I'm confused as to why using SRFI 10 makes things
'second-class,' however.  What makes SRFI 10 degrade the class of what
it is used to represent?  There seems to be a great deal of aversion to
SRFI 10 here that I don't understand.

> Some Scheme implementations may already support Common Lisp's #A syntax.

So they can keep doing so.  Making the #,(ARRAY ...) syntax standard
wouldn't hurt them.  Making the #nA...(...) syntax standard, however,
_would_ hurt simplicity & consistency in Scheme's syntax.

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

OK, but you still haven't given a decent justification of Common Lisp's
array syntax.  All you've said is that you like a couple of features
that Common Lisp supports.

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

Perhaps I'm missing the point you were trying to make here, but I don't
see how this is a good example of how type specifiers could work in
standard Scheme: you've demonstrated that Kawa has a syntax capable of
assigning Java classes/types to Scheme variables, which affects the
Java byte code that is generated.  This does not seem very useful for
other Scheme type systems or for array element representations.

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

I agree that optional static type annotations can be useful.  However,
they are not only _far_ outside the scope of this SRFI but also ill-
suited to the matter of describing array element representations.

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

OK, it seems we violently agree here that the element representation
specifier should be cleanly separated from the ARRAY token, although I
don't consider ARRAY:INT32 to have a clean separation: it would read as
an atomic symbol to Scheme.

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

Since the static type systems of those Schemes that support them tend
to differ incompatibly anyway, I'm not sure how this could be avoided;
however, I don't see how my proposed SRFI-10-based syntax, #,(ARRAY
<rank> <elt-rep> <contents>), is intrinsically incompatible with all of
those systems.  Or perhaps I misunderstood and you were referring to
the current #<rank>A<abbreviated-element-representation>(<contents>)
syntax?