Subject: A possible solution (was: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.) From: Erik Naggum <erik@naggum.net> Date: 2000/11/10 Newsgroups: comp.lang.lisp Message-ID: <3182855319020600_-_@naggum.net> * Tim Bradshaw <tfb@tfeb.org> | 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.