Re: Proper namespaces in Elisp

[Vladimir Sedach <vas@oneofus.la>]

Daniel Colascione <dancol@dancol.org> writes:
> I wouldn't call package-local nicknames "throw[ing] away" the
> namespace system. The post describes a logical extension. Is your
> argument that the CL namespace system (suitably extended) *allows*
> people to do silly things (like :use) even though it doesn't require
> that they do?

Yes, it is silly, and people do it. They will do it in Elisp if you
let them. I think unintended re-definition of short names due to
"namespace multiple inheritance" is going to be a problem for Elisp,
because ordinary Emacs users load code from MELPA. It is a lot
different than encountering the problem in C++ or something when you
are a distribution maintainer compiling binaries. Neither the R6RS
approach of throwing an error, nor clobbering the definition and
showing a warning (what some Common Lisp implementations do) that
will not be paid attention to is appropriate for what should be a
backwards-compatible package update.

> Fair enough. What about requiring that a colon separate the module
> prefix from the remainder of the symbol?

Good question. I think if you leave it open-ended, that can solve the
"s.el prefix is short and bad, but we don't want people to have to
change too much code" problem. Ideally all they would need to do is:

--8<---------------cut here---------------start------------->8---
(declare-namespace legacy-library
  (use elisp29)
  (import modern-string s-))
--8<---------------cut here---------------end--------------->8---

> Using a dash seems ripe for misinterpretation, but someone reading
> a symbol containing colon (in a way that looks vaguely reminiscent
> of CL) would know to look for a namespace alias instead of
> searching in vain for some global definition of st-foo or sy-foo.

That is true. If you use a dash for legacy code, and suggest the use
of semicolon for new code as a convention, that will help minimize
the confusion. I cannot think of a better way.

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