[editor-hints-devel] Re: Comments about defreadtable

Luis Oliveira luismbo at gmail.com
Mon Jan 28 19:35:46 UTC 2008


"Robert P. Goldman" <rpgoldman at sift.info> writes:
> Luis Oliveira wrote:
[...]
>>   2. Readtables should be named by symbols , not strings [...]
>
> 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.

How is it problematic for mode lines?


> I actually think that having all package names share a single global
> namespace is not a desirable feature of CL, but it's not fixable by us,

Agreed, I have seen hacks that implement extra namespaces for
packages. (E.g. in namespace foo, package names a, c and d map to
packages x, y z.) So there is hope. :-)


> and I think the arguments for making readtables act like packages are
> strong.

The only argument I've heard is "that's what defpackage does", which
doesn't seem good enough to me. We wouldn't justify calling
make-package instead of copy-readtable because that's what defpackage
does would we?


> If the CL community is to manage to grow and deal with larger sets of
> libraries, we will have to evolve some kind of convention to avoid name
> collisions across packages, possibly something like the java package
> naming convention, foo.bar.bletch, and we should be able to extend that
> to readtable naming.

I think that supports my argument. If we name readtables using symbols
now, we'll get those features for free later.


-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/




More information about the editor-hints-devel mailing list