[Top][All Lists]

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

Re: Proper namespaces in Elisp

From: Tom Tromey
Subject: Re: Proper namespaces in Elisp
Date: Wed, 06 May 2020 20:23:50 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>>>> "João" == João Távora <address@hidden> writes:

>> https://github.com/tromey/emacs-module

João> So you're saying one just types "s-format", but the actual symbol
João> that elisp sees is modern-string-format?

Yes.  The test program there shows how it is used.

>From testmodule.el:

    (import-module testm2 :symbols (zzzq))
    (defun somefunction ()

>From testm2.el:

    (define-module testm2 :export zzzq)
    (defun zzzq ()

Here, the actual symbol names are "testmodule-somefunction" and

The only things that are renamed are either (1) symbols you import, and
(2) things in your .el file that (after macro expansion) are a defvar,
defconst, defalias, defvaralias, or fset (this handles defuns).

João> Are both symbols interned?  Only for vars&functions? I could live
João> with that.

Not sure I totally understand, but the renaming happens after macro
expansion, so everything is interned.  How exactly the symbol is used is
up to you -- basically the renamer is intentionally simplistic, it just
blindly renames all symbols that were imported.

I guess it is a little too simplistic since looking at
module--rewrite-form, it seems I didn't make it recurse into vectors.
Maybe it would struggle with other things, too, like if macro expansion
resulted in a string with properties applied.

João> It seems similar my "shorthand" idea
João> (https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00617.html)
João> but that idea would fall into the pitfall of:
João>     "the Emacs core sometimes requires certain symbol names in APIs."
João> unless, that is, you added syntax to escape renaming in _those_
João> situations, like `::`

I like the idea of doing it in the reader (it has some nice advantages),
but the downside is it is then harder to special-case defining forms.

Also, in my approach the issue of special symbols that are important to
the elisp core doesn't really arise, because only explicit imports (and
exports) are renamed.  This is essentially the same problem.

Probably functions taking a special symbol should be updated to also
take a special keyword.  That would eliminate this part of the problem

João> I think I could fix the thing-at-point thing reasonably easily.

There's also whatever M-. uses under the hood when in a .el file.
Maybe that's thing-at-point, I haven't looked.

I'm not totally sold on my module approach, but I'm happy to assign it
to the FSF if that's useful.  Emacs could include it or someone could
just lift whatever code they like from it.

One thing I've occasionally wished for in a module system is the ability
to load two different versions of a library simultaneously.  That's not
readily done in this system.  Modules aren't really first class -- the
implementation just reuses the global obarray and the full symbol names
are baked into the .elc.  I tend to think Emacs could do better with
something in the core than what I implemented.


reply via email to

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