emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lexicons


From: Stefan Monnier
Subject: Re: lexicons
Date: Tue, 30 Jul 2013 23:47:58 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> I read the documentation of lexicons, and they seem to solve the
> problems that made me dislike CL packages.

I also prefer the semantics of lexicon over that of CL packages.
But I don't think this would fly for Elisp, because it completely
separates the notion of symbol from the notion of its binding, so things
like (symbol-value 'foo) don't behave like `foo' any more, so it's
a pretty drastic change.

I think what you don't like is this idea of "look around in various
obarrays to find the symbol that is meant".  I tend to agree here: doing
it at compile/run-time (as in the case of lexicons) might be acceptable
(because you can then distinguish definitions from uses), but doing it
at read-time is more problematic, especially when one of the obarrays is
the global one which can hold any kind of random crap thanks to the
myriad of poorly written packages, or because of code copy&pasted from
the web into the user's ~/.emacs.

While some people think that even a 3-letter prefix is completely
unacceptable (I'll let you guess which prefix I'm thinking about),
I tend to think that using prefixes is not that bad, as long as they're
kept short.

But I agree that there's a problem here: we want prefixes in the code to
be short, but namespace cleanliness wants us to use longish prefixes.

So maybe the solution is simply to provide prefix shorthands.
Chose a "prefix char" (there's a good time for bikeshedding here), let's
say | for now.  Then you could define (file-locally):

   prefixes-alist: '(("" "mypackage-") ("gs" "gnus-summary-"))

and then use `|foo' as a shorthand for `mypackage-foo' and `gs|bar' as
a shorthand for `gnus-summary-bar'.

It's still a read-time operation (which means that it will work just
fine with people's bad habits of using ' to quote code and things like
that), but it doesn't suffer from the ambiguity of a search through
various obarrays.

This wouldn't let you "import without a prefix", but it would free
people to use longish prefixes, since you can locally shorten the ones
you care about (a common practice in the SML module system, where you
typically import modules while renaming them to a very short (1 or
2 chars) local name).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]