emacs-devel
[Top][All Lists]
Advanced

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

Re: Proper namespaces in Elisp


From: João Távora
Subject: Re: Proper namespaces in Elisp
Date: Wed, 6 May 2020 20:38:14 +0100

On Wed, May 6, 2020 at 4:38 AM Vladimir Sedach <address@hidden> wrote:

> This is not a dependency failure. It should be possible to
> automatically pull in minor version upgrades that add functionality

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.

So this is a fundamental characteristic of the problem, not any
language. If you want to have names from a different namespace
X addressed without qualification along with other names of
namespace Y also without qualification, either you control X and Y
forever or you expose yourself to these problems.  By definition, if
either X or Y is in a library that you don't  control, then you don't
control them. So _don't_ merge namespaces unless you know
what you are doing. Like anything in programming. Or anywhere.

> There are no warnings. The developer of XYZ developed against ABC
> 1.0, which did not have any warnings.

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.

> In Elisp there would be no warnings period.

How do you know this? Have you seen the future?

> And there would be no warnings if you assign
> variables instead of defining functions.

That's why you `defvar` before assigning, and any decent lisp
(including Elisp) will tell you at compile time if you don't.

> > Or stop `:USE` of packages of systems whose code he doesn't
> > control.
> That is the current recommended practice in Common Lisp-land.

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

> not happen in R6RS. Their solution was to make exported bindings
> immutable. This is not going to work for Elisp.

So it errors when symbols clash? A possible strategy, I guess, but
not really a "solution" because the problem has no solution.
I asked you to show me the problems with CL packages. If you said
:USE is mandatory always, then I would agree with you immediately.
That would be a pretty useless package system, though.

It seems you want a namespacing system that _doesn't_ have
namespace merging. Fine. Let's get one with local nicknames
and you'll use only that.  But full merging is useful, too.  It's the
usual "with great power".

> The real reason Quicklisp seems to avoid this problem is because it
> requires all libraries to build without any warnings, and redefining
> a function causes a warning in some implementations. Re-assigning a
> variable will not give any warnings and may not show up in unit
> tests, so this problem is still possible.

Again, you can't assign a variable without having it defined
first, or you get a warning, so there's a contradiction there
somewhere.

> 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?

To wrap this up:

- I understand your :USE situation, thank you very much;
- Don't merge namespaces that you don't control;
- For development, the compiler warns on redefinition. You
  can choose not to load a compilation unit that warned.

João



reply via email to

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