[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-10 syntax vs. #nA syntax
| Date: Mon, 3 Jan 2005 15:22:48 -0800 (PST)
| From: Taylor Campbell <campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
| On Sun, 2 Jan 2005, Aubrey Jaffer wrote:
| > The current state of SRFI-58 is a compromise. It is likely that none
| > of us are completely happy with the choices (I prefer shorter
| > prefixes), but SRFI-58 tries to balance the major concerns expressed
| > by the participants.
| This is hardly a compromise at all.
If it is not a compromise, then whose plan is it? My proposal
(implemented in SCM) used SRFI-4 abbreviations. Per Bothner wants
FLOAT, -U, and -S for names. Bear wants square brackets.
| All that has been done is change a minor point I mentioned in
| passing (which I am thankful for you having fixed), namely the
| naming scheme of array element representations;
You did a good job, moving us toward Scheme vocabulary and away from
bastard C types.
| now the syntax is still as complicated -- perhaps even slightly
| more so --, not possible to implement based on SRFI 10, and even
| incompatible with Common Lisp & SLIB!
The heterogeneous arrays are compatible with Common-Lisp:
#1A (foo bar)
#2A ((foo bar) (bar foo))
Since SLIB does not specify read-syntax, there is no read-syntax
incompatibility between SLIB and SRFI-58. As for the new prototype
names, they are directly provided by the 13 definitions in SRFI-58:
(define A:complex-64 ac64)
(define A:complex-32 ac32)
(define A:real-64 ar64)
(define A:real-32 ar32)
(define A:integer-64 as64)
(define A:integer-32 as32)
(define A:integer-16 as16)
(define A:integer-8 as8)
(define A:integer+64 au64)
(define A:integer+32 au32)
(define A:integer+16 au16)
(define A:integer+8 au8)
(define A:boolean at1)
| > The use of SRFI-10 syntax for Arrays was discussed. The main
| > arguments in favor of SRFI-10 were:
| > SRFI-10 is for Scheme extensions, and thus appropriate for SRFI-47
| > arrays if they are not incorporated into R6RS.
| > My efforts are directed toward making multidimensional arrays
| > part of R6RS. Multidimensional arrays have been an integral
| > part of computing since before electronic computers. A supposed
| > general-purpose computer language without multidimensional
| > arrays is an oxymoron.
| This is an argument that has been repeatedly cited in the totally wrong
| context. This is an argument for having arrays at all. What is in
| question here is the _syntax_ for arrays.
No new transparent type has been added to Scheme reports in over 20
years. Having observed the process of creating R4RS and R5RS, I
learned that proposals which aren't completely and thoroughly thought
out will not be adopted; there is a huge bias toward inertia.
Here are the procedures and syntax of Scheme's three transparent
list? vector? string?
list vector string
length vector-length string-length
list-ref vector-ref string-ref
(...) #(...) "..."
Scheme numbers also come with predicates, conversion procedures, and
syntax. Would the R6RS-editors adopt arrays without a
read/write-invariant syntax? It doesn't look likely.
| SRFI 10 is for consistent & simple extension of Scheme's syntax,
| which is fundamentally centred around lists & symbols, but which
| has nothing to do with arrays at all. I do not deny that arrays
| are a very important thing to have. They should not, however,
| completely unnecessarily complicate an otherwise almost unmarred
| syntax that is one of the hallmarks of Scheme. Arrays are
| fundamental to computing, yes, but not fundamental to Scheme's
My array procedure missive may have crossed in the emails. It
provides a trivial extension to SRFI-10 syntax, and an even more
useful form (supporting UNQUOTE) as a procedure.
-- Function: array rank protothunk contents
RANK must be a nonnegative integer. PROTOTHUNK must be a
procedure of no arguments returning an array. CONTENTS must be a
RANK-deep nesting of lists or vectors. For RANK = 0, CONTENTS
can be any object.
`array' creates and returns an array of the type returned by
calling PROTOTHUNK with no arguments. The returned array has
RANK dimensions; and elements taken from CONTENTS in one-to-one
correspondence, the innermost lists or vectors corresponding to
the rows (the last index).
Calls to `array' look very much like SRFI-10 read-syntax:
(define ident2 (array 2 A:real-32 '((1.0 0.0) (0.0 1.0))))
(define ident2 #,(array 2 A:real-32 ((1.0 0.0) (0.0 1.0))))
| > Literal arrays would not be used often enough to warrant a "#"
| > syntax.
Even if you have more experience writing Scheme code than I do, your
opinion of the usefulness of literal arrays has no bearing on my or
other's experience. I have been using arrays in Scheme for years; I
want array syntax.
| > The proposed "#nA" syntax consumes too much of the precious "#"
| > name-space.
| > The claim is that SRFI-58 would consume ten characters (the ten
| > decimal digits), far more than the single "(" used for vectors.
| > But this accounting is disingenuous. It is highly unlikely that
| > a one digit "#" code, say "#5" would be registered without
| > including the other digits. If we consider "#" followed by
| > digits to be a numeric argument to the character following, then
| > only one letter, "A", worth of name-space has been allocated.
| > "#nnn" followed by the letters B-Z and punctuation are all
| > available.
| This, too, complicates the syntax unnecessarily.
Whether it is necessary or not is a matter of opinion.
| (For what it's worth, by the way, I didn't think it was a good idea
| to introduce the literal vector syntax back in R2RS.)
R2RS? Wow, maybe you do have more experience! But the rrrs-authors
have spoken; the reports clearly favor read/write invariant notations.