Re: Question named-readtables

Steve Haflich <[email protected]> writes:

>    From: Luis Oliveira <[email protected]>
>    
>    I have a quick question about Allegro's named-readtable facility. What
>    is the rationale for restricting the names to keywords? It seems to me
>    that using symbols would help avoid naming conflicts between similarly
>    named readtables from multiple codebases.
>
> I'm the one who implemented Allegro's named-readtable facility back
> around 1991.  I can't necessarily remember all the thinking behind it,
> but I though that I copied the basic concept from Symbolics.  However,
> yesterday when I was in the office I checked a full set of Genera
> documentation and could find nothing at all documenting named
> readtables.  Can anyone suggest where the idea might have come from?

Symbolics had "Syntax: FOO-LISP" file variables. I assumed it was
inspired there from.


> Anyway, you are correct that allowing arbitrary symbols to be used as
> readtable names would reduce the possibility of collision, but no
> application ever uses more than a few readtables so the probability of
> collision in practice is essentially zero.  

That's the same kind of reasoning that I assume was due back when the
package system was incorporated from Symbolics into Common Lisp: Back
then, a flat namespace just made sense, as it was the time of the big
Lisp environments, and they strived for a solution to organize the
source code namespace mostly _inside their environment_. It's kind of
the same reason that a flat namespace also works for GNU Emacs most of
the time.

However, the world does look differently now where many Lisp
implementations are mostly just an implementation, and not an
environment. The environment is built (at least partially) from Open
Source packages. And there it shows that a flat namespace is not enough
(especially wrt. versioning.)

The same applies to named readtables. Think of FOO:SQL-SYNTAX
vs. BAR:SQL-SYNTAX. 

Another advantage of allowing whole symbols as named readtable
designators is that it's fully future proof. However the package system
is going to be tweaked, it's very likely to retain backwards
compatibility, such that symbols will just do the right thing.



> Also, coercing to keywords means that an Emacs variables line can look
> like this
>
>   ;; -*- mode: common-lisp; package: user; readtable: xml -*-
>
> instead of like this
>
>   ;; -*- mode: common-lisp; package: user; readtable: :xml -*-
>
> Do you really think that the collision possibility is an important
> issue here?  The mode line examples above show that changing the
> package handling would not easily be back compatible.

Good to know. Thanks! I'd be inclined to do it the following way:

  If encountering "xml", check if "user:xml" names a readtables; if not,
  check if ":xml" does; if not, use the standard readtable.


  -T.