[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: #\a octothorpe syntax vs SRFI 10



bear wrote:

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

Suggestion 1:

A two-by-two array of unsigned 16-bit integers:

#2a:int16((0 1) (2 3))

Suggestion 2:

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)))
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/