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.
Before I get to responding to the content of this message, let me first
state my position on square brackets for arrays.
I think it would be much better to leave this SRFI as it is with regard
to parentheses versus square brackets and later have a SRFI, or perhaps
have it in R6RS, to make square brackets equivalent to parentheses.
There is, first of all, a great deal of existing code written with that
extension: it is a very wide-spread one. It would also be possible to
write arrays using square brackets, as suggested by Aubrey Jaffer, in
order to make the array dimensions clearer, if so desired, and, though
it would require explicitly writing the rank, I don't think that that
is a particularly crucial matter.
I'm opposed to any specialized square bracket syntax for arrays, and
very strongly so to such a complicated syntax as bear proposes. Scheme
is not APL; it is intended to have a very simple & consistent syntax
with as few extensions as reasonable, and SRFI 10 is there precisely to
obviate the need to add many new such inconsistent extensions. It's
not there just to look nice: it should be put to use. Scheme is also
not an array-oriented language, and I sincerely doubt that the extra
few characters added to the literal array syntax make enough of a
difference to warrant condensing them into square brackets, which would
break a large quantity of existing code.
On Thu, 30 Dec 2004, Aubrey Jaffer wrote:
> In the updated srfi-58.html I sent to the editor I have eliminated the
> #Axxx syntax. The rank digit(s) will be required.
OK. I have no objections to that.
> | Perhaps I'm confused, but I don't see much difference between my usage
> | of symbols -- which exist only at read-time, never at run-time, unlike
> | nil and the EOF object -- and your usage of the suffixes of the new #A
> | syntax. Could you elaborate on how my proposal is any worse in that
> | respect than yours?
>
> To keep symbols-as-cookies out of Scheme to this point probably means
> that some RRRS-author(s) is severly allergic to it.
>
> I want arrays in R6RS. I don't want to jeopardize array's chances by
> making a proposal which looks like symbols-as-cookies, even if it is
> not exactly true in a technical sense.
I believe that there is aversion only to using symbols at run-time in
specialized cases. For example, it would be stupid to make the EOF
object be a symbol: READ could return it when not at the end of a port.
There is already use of 'symbols-as-cookies'; consider, for example,
the COND & CASE macros, which use ELSE, or in general the list of
literal identifiers in SYNTAX-RULES.
> SRFI-10 mandates parentheses (eg. #,(infinity) instead of #,infinity).
> This makes its SRFI-10 objects look like expressions to be evaluated.
> SRFI-58 objects will be used as prototype array objects in calls to
> MAKE-ARRAY:
>
> (make-array '#1Ar64(1.0) 2 3) ; Current SRFI-58 syntax
>
> (make-array '#,(Array 1 ar64 [1.0]) 2 3) ; SRFI-10 style
>
> (make-array '#,(Ar64 [1.0]) 2 3) ; compact-SRFI-10 style.
> ; [] nesting gives rank.
>
> (make-array (Ar64 1.0) 2 3) ; Current SRFI-47 functions
>
> ==> #2Ar64((1.0 1.0 1.0) (1.0 1.0 1.0))
>
> The SRFI-10 style above looks like symbols-as-cookies. The
> compact-SRFI-10 style does not.
I still don't see why that is the case. How is AR64 any less a 'symbol
as a cookie' when it comes as the car of a list or before the array's
parentheses than when it comes as the cadr of a list?
> Do you like the compact-SRFI-10
> style; or would it take too much of SRFI-10s namespace?
I think it is better to clearly mark 'array': a single 'A' is not
sufficient. I also think it is pointless to combine ARRAY with the
element type specifier: this introduces no benefits I can see, but it
complicates both human and machine parsing, because the token has to be
parsed all at once and then split up, or one must remember a number of
different tokens that have a very similar meaning. (E.g., I could just
define a single SRFI 10 constructor for ARRAY that could just construct
an array from the given type specifier. If ARRAY were conjoined with
the type specifier, there would have to be a number of different SRFI
10 constructors that could not be easily or elegantly unified.) On the
other hand, a single space could split the two tokens up and thereby
make it clearer to both machine and human.
> Having the read prefix use the same coding as the prototype functions
> halves the (human) memory load. If we move to nomenclature like
> REAL-64, then I want prototype functions to be available with those
> names:
>
> (make-array '#,(Array 1 real-64 [0.0]) 2 3) ; longer SRFI-10 Style
>
> (make-array '#,(real-64 [0.0]) 2 3) ; longer compact-SRFI-10
>
> (make-array (real-64 0.0) 2 3) ; analogous SRFI-47 function
The 'longer SRFI-10-style' one is the only one I don't object to. It
includes both ARRAY and a more clearly written 'REAL-64.' (REAL-64
0.0) looks like it's coercing 0.0 to be a 64-bit real number; likewise
with #,(REAL-64 [0.0]), only with a set of extraneous brackets.
> | This works for SRFI 47, but not necessarily this SRFI: one cannot
> | define one's own aliases for existing array types in the reader
> | syntax.
>
> Yes. That is why we are dicussing this now; before SRFI-58 is
> finalized.
OK, although I'm allergic to inconsistency like this between SRFI 47's
procedures & SRFI 58's array element type specifiers. If there is to
be any inconsistency, I'd rather that the procedure names be longer
while the type specifiers for the literal array syntax be shorter, but
that's rather moot at this point.
> | I'm not suggesting names so long that they induce tedium in typists,
> | but rather names somewhat longer than are excessively obscure, such as
> | INTEGER-U16, COMPLEX-64, BIT, et cetera.
>
> This is requiring users to internalize assumptions that integers are
> exact; and reals and complexes are not.
This is no different from the current naming scheme, however, where you
have to remember not only that integers are always exact, and complexes
& reals may not be, but also that 'i' stands for 'integer,' 'r' stands
for 'real,' &c.
(Complexes, as far as I know, can be either exact or inexact, by the
way. I'm not sure about reals, but I think they theoretically can be,
too. (This is, of course, ignoring the number tower.) If there were
to be both exact & inexact complex arrays, and the same for reals &
integers, I'd not mind adding the token.)
> English doesn't much help remember Scheme exponent markers:
>
> The letters `s', `f', `d', and `l' specify the use of SHORT, SINGLE,
> DOUBLE, and LONG precision, respectively.
>
> I don't usually think of a DOUBLE as shorter than a LONG. And where
> did `f' for SINGLE come from? Maybe it is a C-ism. In any case, it
> is one of five characters (with 'e') rather than one of five longer
> sequences to remember.
Although I don't have a better suggestion for the number syntax, I
can't claim to like it as it is, either, and I think there are many who
share my sentiments. (I have certainly spoken to a number of them, and
I recall a great deal of discussion over confusion in the number syntax
on RRRS-authors in the past. Bear seems to agree with me here.)
> | Let me also point out here that much of Scheme's naming conventions
> | and lexemes originated from T. In T, there was no built-in
> | facility for multi-dimensional arrays, but there were still object
> | representation names used by Orbit's representation analyzer and
> | for the C & Pascal FFIs. These were named semi-verbosely, as I
> | suggest above; e.g., the representation descriptor of unsigned,
> | sixteen-bit integers was named REP/INTEGER-16-U. Many of the names
> | in T were intended to be long enough to be understandable and not
> | obscure, but not so long as to be excessive; this has tended to
> | hold in Scheme as well. I think it would be good to preserve that
> | in the array element type names as well.
>
> I found my T2.7 manual, but it doesn't have FFIs in it.
Sorry, I meant T 3.1. There are several copies of the manual in a few
different formats at
http://www.bloodandcoffee.net/campbell/t/
A document describing just the FFI is also available here:
http://www.bloodandcoffee.net/campbell/code/t-ffi.tex
On a note unrelated to SRFI 58, do you still have any other T 2.7
resources available that you could send to me? I'd be interested in
anything: the manual, the source, libraries, &c.
> If I come up with longer names and they aren't better than the current
> system (used by SCM for many years), then I would be making a
> straw-man. Please replace the first column of this table with a set
> of better names, so we can discuss this change in more concrete terms.
Here are my suggestions:
prototype
procedure exactness element-type
========= ========= ============
object any (conventional vector)
complex-64 inexact 64-bit+64-bit complex
complex-32 inexact 32-bit+32-bit complex
real-64 inexact 64-bit real
real-32 inexact 32-bit real
Note, by the way, the messages on the SRFI 4 list regarding reals
versus floats, so it might be FLOAT-64 & FLOAT-32 instead. I
have nothing substantial to say on the matter, however.
integer-64-s exact 64-bit signed integer
or integer-s64 or something of that variety
(likewise for the other integer types)
integer-32-s exact 32-bit signed integer
integer-16-s exact 16-bit signed integer
integer-8-s exact 8-bit signed integer
integer-64-u exact 64-bit unsigned integer
integer-32-u exact 32-bit unsigned integer
integer-16-u exact 16-bit unsigned integer
integer-8-u exact 8-bit unsigned integer
char char (string)
bit or boolean boolean (bit-vector)
I think the names would be OK without the hyphens, too, as long as, for
the integer specifiers, the U/S is kept on the right of the number; for
example, INTEGER16U.