[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
My own preference would be something like [3 instead of #A3(
Let's not invent new confusing syntax when we have existing
confusing syntax that is just as good ...
Array syntax should be compatible with Common Lisp's notation.
Anything else requires a *really* strong justification.
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.
(See below for more on this.)
A two-by-two array of unsigned 16-bit integers:
#2a:int16((0 1) (2 3))
Many Scheme use <TYPENAME> by convention for class- an/or type-names.
We could incorporate this syntax:
#2a<int16>((0 1) (2 3))
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>. 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)))