Re: Proper namespaces in Elisp

[Vladimir Sedach]

João Távora <address@hidden> writes:
> I would also prefer CL packages but if a lower
> effort thing can solve _some_ problems, and be backward compatible
> and not slow down compilation, maybe we should give it a shot.

The one big problem with the Common Lisp package system that should
not be copied over is the package :use mechanism:

--8<---------------cut here---------------start------------->8---
CL-USER> (defpackage "ABC" (:use "CL") (:export "FUNC1"))
#<PACKAGE "ABC">
CL-USER> (defun abc:func1 (x y) (list x y))
ABC:FUNC1
CL-USER> (abc:func1 1 2)
(1 2)
CL-USER> (defpackage "XYZ" (:use "CL" "ABC"))
#<PACKAGE "XYZ">
CL-USER> (defun xyz::func1 (x y) (+ x y))
WARNING: redefining ABC:FUNC1 in DEFUN
ABC:FUNC1
CL-USER> (abc:func1 1 2)
3
--8<---------------cut here---------------end--------------->8---

This causes problems when a new version of a library introduces a new
function FUNC1, which definition gets unknowingly overridden for
everybody by another package that uses the library. Explicitly using
:import avoids this problem, and makes figuring out who-uses-what
easier.

There has been lots of talk about the reader here, but no one has
brought up the printer. Any namespace system is going to have to
print symbols in a way such that they can be read back in EQually.

Common Lisp does not do a good job of this, because whether or not a
symbol's package prefix is printed depends on the current package you
are in when printing.

Any namespace system is going to have to be first-class itself, with
first-class identifiers (otherwise see Python, where code cannot be
re-loaded correctly depending on how import was done), which implies
full introspection support. Any system that makes it a chore to
re-define functions outside of the files they were defined in should
be rejected.

Namespaces are helpful for organizing code in a project, but they are
not going to stop people from naming their packages with one or two
or three letter names (happens with Common Lisp libraries all the
time), or stop people from naming their packages in a way that
conflicts with older libraries they were not aware of (also happens).
Those two arguments are not valid ones for introducing a namespace
system.

> Anyway, are there any contemporary objections to Nic's plan

I think a namespace system could be useful for:

1. Keeping people from accidentally defining and dynamically binding
   symbols they did not mean to in their packages.

2. Describing autoloads in a convenient first-class way. "Magic
   comments" and decorators are a terrible hack for defective
   languages; there is never a real need for them in Lisp. Same
   reason why any proposal that suggests declaring namespaces in
   comments should be rejected (my major objection to Nic's
   proposal).

3. Make it easier for people to see what commands/functions/variables
   a package provides, because they are all declared to be exported
   in a single place, and can also be queried from code because the
   namespace system is first-class and introspective.

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