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: 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:
#0A foo
#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
aggregate types:
list? vector? string?
list vector string
length vector-length string-length
list-ref vector-ref string-ref
append string-append
make-vector make-string
vector->list string->list
list->vector list->string
vector-set! string-set!
vector-fill! string-fill!
(...) #(...) "..."
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
| syntax.
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.