Re: #\a octothorpe syntax vs SRFI 10
Aubrey Jaffer 31 Dec 2004 18:54 UTC
| Date: Thu, 30 Dec 2004 20:53:37 -0800
| From: Per Bothner <xxxxxx@bothner.com>
|
| 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).