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

Re: #\a octothorpe syntax vs SRFI 10



 | Date: Thu, 30 Dec 2004 20:53:37 -0800
 | From: Per Bothner <per@xxxxxxxxxxx>
 | 
 | 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))

Using a delimiter inside the #-tag is an excellent idea!
How detailed should the type specifier be?
Is int16 signed or unsigned?

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

Early versions of MAKE-UNIFORM-ARRAY took a type-specifying argument
as you suggest.  There were several problems:

(Functional) APL operators must construct new arrays of the proper
type, usually the same type as an argument array.  This required a
procedure to extract the type from an array.  In an implementation
that did not support the full panoply of SRFI-47 types, this
ARRAY-TYPE procedure exposed the underlying uniform-type support.

Code which used ARRAY-TYPE conditioned its range-checking and coercion
on the type of the storage, rather than the type the coder intended.
This led to platform-dependencies in the execution of code using
arrays.

A separate intended-type could have been stored with the array.  But
this meant the Scheme vectors could no longer simply be the default
rank-1 arrays; they would have required wrappers.

The arrangement in SRFI-47 portably solved both the type specification
and initial value problems (how to specify uninitialized array
contents to MAKE-ARRAY) in a single argument.

I find SRFI-47 uniform arrays work well in Scheme applications like
image processing and computer graphics, sequence comparison, and EM
field calculations (optics) and spectra (color).