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

Re: #\a octothorpe syntax vs SRFI 10

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.



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