[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: COMMON-LISP at SU-AI
- Subject: Array proposal
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Thu, 09 Sep 1982 07:11:00 -0000
Date: Wednesday, 8 September 1982 18:25-EDT
From: MOON at SCRC-TENEX
... The CHAR and BIT functions can go away since they are just duplications
of AREF. Programs for some implementations might want to define macros
that generate AREF with a THE declaration...
I disagree with this. While it may be the case that you will want to make
CHAR and BIT trivially turn into just AREFs, I think they have value in terms
of self-documentation. Particularly, I would rather see:
(DEFUN FIRSTCHAR (STRING) (CHAR STRING 1))
(DEFUN FIRSTCHAR (STRING) (AREF STRING 1))
even if the two were identically efficient. Also, automatic translators to
dialects or languages not part of Common Lisp will have a considerably easier
time if people use programs that make a visual distinction between characters
and arrays even if there is not one so that useful optimizations may be done
where appropriate. I imagine this would help out the T group considerably when
it comes time to write a Common Lisp compatibility package.
Further, I don't even know what you mean by "Programs for some
implementations...". I thought the whole idea behind Common Lisp was that
code should port well from implementation to implementation. If people on
the LispM write code using AREF because they know it'll be fast there, then
they're throwing away useful information that would allow their code to run
faster in some other implementation. If you don't expect people to write code
for the LispM which is to be ported to machines that'll need declarations,
then I think you're drifting from the goals fo a common lisp.
Making all vectors (1-D arrays) default to printing is wrong. What's
so special about 1-dimensionality. Arrays created by typing in the #(...)
syntax would have their printing-bit set, of course....
I thought the idea was that vectors should be simple and effectively
"option-free". They should not waste a lot of space storing information like
how they print. They're mostly a hack to allow implementors to write lots of
fancy optimizations. If you start hairing them up with things like print
options, pretty soon you'll be back up to the level of arrays. I support the
idea that they should all follow some set of fixed print conventions.