Re: Proper namespaces in Elisp

[Vladimir Sedach]

João Távora <address@hidden> writes:
> Anyway, it sounds like you're describing dependencies failure. The
> author of XYZ should probably say that his package requires ABC
> 1.0.

This is not a dependency failure. It should be possible to
automatically pull in minor version upgrades that add functionality
in a backwards-compatible manner (the MINOR part of MAJOR.MINOR.PATCH
in Semantic Versioning). ABC 1.1 adding a new function does not break
backward compatibility.

> Or start paying attention to warnings.

There are no warnings. The developer of XYZ developed against ABC
1.0, which did not have any warnings. In Elisp there would be no
warnings period. And there would be no warnings if you assign
variables instead of defining functions.

> Or stop `:USE` of packages of systems whose code he doesn't
> control.

That is the current recommended practice in Common Lisp-land.

> This is a problem that happens in other languages.

I was out of the loop on R6RS, and spent the afternoon reading up on
the R6RS library system to see the Scheme take on the issue.
Obviously the R6RS committee recognized this problem, because it does
not happen in R6RS. Their solution was to make exported bindings
immutable. This is not going to work for Elisp.

In contrast, Guile's module system has the same behavior and problem
as Common Lisp.

> Also note: I don't know what you use to "pull in dependencies",
> but quicklisp in particular won't let this happen, since it works
> in distributions.

AFAIK MELPA does not.

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.

That does not address the problem of an Elisp package that wants to
re-define/patch some function in another package on purpose. That
happens in Elisp a lot more often than it does in Common Lisp.

> So the things you think happen, really just don't happen IRL.

I don't know why you keep insisting this.

If you don't believe me, you can ask in
ircs://chat.freenode.net/#lisp

This is a very real problem that has to be addressed in any Elisp
namespace system. Importing all exported symbols seems like a useful
and harmless operation, but counter-intuitively it can lead to worse
namespace conflicts. You think you are safe to use short names
because you are in your own private namespace, but then you end up
unknowingly and unintentionally redefining something.

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