From ...
From: Erik Naggum
Subject: A possible solution (was: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.)
Date: 2000/11/10
Message-ID: <3182855319020600_-_@naggum.net>#1/1
X-Deja-AN: 692034605
References: <3A0618EA.B29DB165@fisec.com> <3A06E0ED.6016BA05@pindar.com> <3A07D26A.4B4EF01C@pindar.com> <8kqh0tsagfvji7p7p7rnodq3ep3fghv2qo@4ax.com> <3182670917871449@naggum.net> <18ti0t0tgl4u3h5fkubbaiul5c0tl082o9@4ax.com> <87vgtyidnv.fsf@asaka.latnet.lv> <87vgty73ad.fsf@asaka.latnet.lv>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 973867042 5960 195.0.192.66 (10 Nov 2000 14:37:22 GMT)
Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
Mime-Version: 1.0
NNTP-Posting-Date: 10 Nov 2000 14:37:22 GMT
Newsgroups: comp.lang.lisp
* Tim Bradshaw
| It seems to me that this would be hard. Although I disagree violently
| with the way modern mode happens at the moment, I think that if it is
| the case that (symbol-name 'car) is "car" there really is going to be
| some problem having unification. I realise that you (Kent) perhaps
| don't want that to be the case, but I can't see a way around it.
I do not think there will be a problem. Franz Inc has pointed out a
number of issues inherent in assuming the case of symbols and I think
this is a good starting point for what a proposal must address to make
Common Lisp "unspecified-case". Most of these issues have to with a
single global value that affects everything. That is bad engineering,
so let's remove that problem-causing solution from our solution space
and focus on how designed-in flexibility and tolerance would look.
| However, I do like the idea of being able to `copy' packages, which I
| think you mentioned, and I've thought of. The problem I can see with
| this is that the compiler (or interpreter) may have all sorts of
| places where it says (if (eq x 'car) ... ...), and that's not going to
| work, instead it would have to test some property of the symbol which
| could be copied.
I do not see any problems with this, either. We merely need to
rethink how we represent the name of a symbol. Unbeknownst to most
people, Allegro CL _already_ contains both lower-case and upper-case
symbol names in a clever way wherein converting case just moves an
internal string pointer in most cases. This _should_ be done in the
symbol object itself, not via string pointer hackery, meaning that
each symbol would have an upper-case version and a lower-case version
of its print name. The global setting that affected the symbol naming
would then cause the appropriate symbol name to be retrieve, and the
need to make truly global changes and different images would vanish.
That global setting may then be as flexibly local as readtable-case.
But most importantly, very little work needs to be done to intern and
other internal symbol-aware functions to ensure that the duplication
takes place hidden from user view. In a transition period, you don't
neve need to store more than the upper-case version of the symbol in
the symbol, using, say, a symbol-indexed hash table with a maximum
size to store the converted lower-case names to save on that space.
This means that a lower-case Lisp may be built on top of a conforming
ANSI Common Lisp by shadowing-importing a few external symbols from
the COMMON-LISP package, and any vendor can easily roll these into the
standard image. As I see this, we wouldn't even have to violate the
standard globally in any way.
The only point that needs addressing is how to specify the reader
"mode" in a per-file manner. Kent Pitman's in-syntax macro is a good
starting point. Franz Inc's named readtables features is another good
feature. In addition to *readtable*, the new special variable that
controls symbol-case must be bound across load, etc, too.
We need to think outside the box to solve this issue, or outside the
typecase, as the case may be (all bad puns unfortunately intended :).
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.