Subject: A possible solution (was: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.)
From: Erik Naggum <>
Date: 2000/11/10
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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 :).

  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.