Re: Proper namespaces in Elisp

[Vladimir Sedach]

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

> On Wed, May 6, 2020 at 4:38 AM Vladimir Sedach <address@hidden> wrote:
> Let me start with a fact from another non-Lisp language. If in
> C++ (where you people that have the the very same
> misunderstanding BTW) you abuse the "using" directive correctly
> you run into the the very same situation.

"C++ does it wrong" is not an argument for anything. C++ does
whole-program static compilation, and users of C++ programs do not
have the need to load and re-define code at run-time, and do not
regularly pull updates for libraries from MELPA.

Since Scheme is also mostly used for whole-program static
compilation, the R6RS approach is appropriate there. Elisp is not
used that way.

> Yes, and because she decided to use :USE for a package that is
> outside her control, she is obligated to register somewhere that her
> library only supports <=1.0.  It's very simple. It's not related to
> CL at all.

Trying to solve this as a dependency management problem is not going
to work.

> Where, pray tell, is this Village of Dubious Recommendations? :-)

I first learned about this in ircs://chat.freenode.net/#lisp from the
many experienced Common Lisp programmers there.

> So it errors when symbols clash?

When they clash, and when you try to re-define an exported symbol:

--8<---------------cut here---------------start------------->8---
Chez Scheme Version 9.5
Copyright 1984-2017 Cisco Systems, Inc.

> (library (ABC) (export FOO) (import (rnrs)) (define FOO 111))
> (library (XYZ) (export) (import (rnrs) (ABC)) (define FOO 222))

Exception: multiple definitions for FOO in body (library (XYZ) (export) (import 
(rnrs) (ABC)) (define FOO 222))
Type (debug) to enter the debugger.
> (library (XYZ) (export) (import (rnrs) (ABC)))
> (import (ABC))
> (set! FOO 222)

Exception: attempt to assign immutable variable FOO
Type (debug) to enter the debugger.
>
--8<---------------cut here---------------end--------------->8---


> A possible strategy, I guess, but not really a "solution" because
> the problem has no solution.

There are many different solutions, some better than others.

> Fine. Let's get one with local nicknames and you'll use only that.

That is one possible solution I had not even thought of. Relevant
reading:

https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3

In Andrea's scheme (which I am in favor of), one possible solution
would be assign a new binding in the local namespace when an imported
symbol is re-defined. I think this could work for dynamic scoping if
you use the binding instead of the symbol for the lookup, but I have
not thought the problem fully through yet. Then, when you really want
to re-define something in another package, you can use something like
the Guile @ and @@ module access special forms (@ is for exported
symbols, @@ for internal; see section 6.20.2 Using Guile Modules of
the Guile manual):

(set! (@ (GNUS ABC) FOO) 456)

There are two things to note from the above:

1. The Common Lisp PACKAGE:SYMBOL syntax is infix in disguise. As I
   noted previously, it also complicates printing and reading
   s-expressions. The Guile approach does not have this problem and
   does not need changes to the reader.

2. The Scheme convention of naming namespaces with a list of symbols
   is a good way to organize namespace, and avoids the complications
   of hierarchical namespace systems and the problem of trying to
   express structure in a string or symbol name.

The Scheme approach would be very inconvenient when in an IELM REPL
or *scratch* buffer (it is annoying enough in Scheme), and it is not
going to work for M-x execute-extended-command.

How namespacing is going to work with commands is another important
consideration that has not been brought up.

>> If you don't believe me, you can ask in
>> ircs://chat.freenode.net/#lisp
>
> What should I ask? "has anyone here ever misused the package
> system? or written bad code"? Doesn't sound very interesting. And
> if those people have something to add, they can do it here, no?

You can ask other experienced Common Lisp programmers about defining
packages and the pitfalls of :use. A lot of people there have strong
opinions and useful recommendations.

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la