[editor-hints-devel] Comments about defreadtable

[Robert Goldman]

Luís Oliveira wrote:
> On 28/01/2008, Robert P. Goldman <rpgoldman at sift.info> wrote:
>>>   2. Readtables should be named by symbols, not strings, in order to
>>>      avoid collisions between different code bases. Also, I suggest
>>>      defreadtable should signal a warning (or a style-warning) if a CL
>>>      or KEYWORD symbol is used to name a readtable. Again, the goal is
>>>      to avoid collisions.
>> I don't actually agree with this point.  Tobias has tried here to make
>> readtables act like packages, and this change would destroy that
>> commonality.  It would also make the use of readtable specifiers in mode
>> lines problematic.
> 
> I've heard that argument before. It makes perfect sense to follow the
> feel of defpackage because we're dealing with similar mechanisms. I
> think that using strings to designate readtables might be pushing the
> metaphor a bit too far, though. I think it's somewhat obvious why
> package names aren't symbols, the circularity makes my brain hurt; it
> doesn't apply to readtables.

Actually, I don't think it would be bad to have package names being
symbols --- that would apply a modularity and scoping that we sorely
lack in the package system.

Given that we lack this in the package system, we must come up with a
naming convention to overcome the lack.  Since we have to do this,
anyway, I'm inclined to suggest we just extend the same mechanism to
readtables, to keep the parallelism.

This is probably an aesthetic disagreement where neither of us will
convince the other.  I think that if we have to introduce foo.bar
package names, we might as well have foo.bar readtable names.  You find
this disturbing.  On the other hand, I find the idea of foo:bar
readtable names disturbing, because it violates the package/readtable
parallelism.

I don't think either of these positions is clearly wrong.  I don't agree
with your position on the tradeoff, but I understand the rationale.

We've each stated our position, I propose that whoever is excited enough
about this to make it work should carry on from here with his/her own
preference.

FWIW, the starting motivation on my part was simply to provide SBCL and
other lisps with compatibility with the ACL named-readtable facility.  I
didn't actually mean to step into such a large undertaking!  So maybe
this limited aspiration is a bias in my choice.

> 
> How is it problematic for mode lines?

I'm concerned that one may be opening the lisp file in emacs in a state
in which the package is not available.  If you are to start interpreting
or compiling code in the file, of course, the package would have to be
in place, but I'm concerned that the emacs+lisp ensemble might get
confused if there's a period after the file is loaded into emacs and
before the package-qualified symbol designator in the mode line becomes
valid.

Best,
R