This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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 per@xxxxxxxxxxx http://per.bothner.com/