Re: Proper namespaces in Elisp

[Andrea Corallo <akrl@sdf.org>]

Andrea Corallo <akrl@sdf.org> writes:

>> Well, let's have "all its implications" then. Because you've done
>> nothing more than describe in simplified fashion what it does,
>> and that's not an argument to support the contention that
>> "it is a bad idea".
>
> Here is a first simple implication of namespace at read-time:
>
> #+SRC_BEGIN lisp
>
> (make-package :xxx)
> (in-package :xxx)
> (defun foo () 'aaa)
> (export 'foo)
>
> (make-package :yyy)
> (in-package :yyy)
> (use-package :xxx)
>
> (if (not (eq (foo) 'aaa))
>     (print "boom"))
>
> #+END_BEGIN
>
> This is because foo is not returnig 'aaa' but 'xxx::aaa'.
>
> It will be told that you have to export also 'aaa' from the package xxx
> because "leaking symbols" is bad.  But in reality this implies you have
> to identify all execution paths that can leak a symbol and remember to
> export these syms otherwise you'll get subtle bugs for any symbol leaked
> passed in any kind of object.
>
> Sure can be done (it is done) and we all got used to that but is just a
> source of bugs due to bad design, not a feature.

OTOH in elisp we would write:

(defun xxx-foo ()
  'aaa)

and not

(defun xxx-foo ()
  'xxx-aaa)

And this because we are smarter then the reader :)

> One should import from a package *bindings* not symbols.  Unfortunatelly
> the implementation can't distinguish those at read time because those do
> not exists already.
>
> With all the goodies of CL packages are really not the best example to
> look at :)
>
>>
>>> I think Emacs has most of the infrastructure to implement this already
>>> in the codebase but right now I've not time to work on a prototype (
>>
>> I too think a dumb man's namespacing can be implemented,
>> just to alleviate this alias-all-the-functions pressure.  Did you
>> read my shorthand idea, I think it could fly.
>
> I don't think the soulution should be dumb, and I think we should aim
> for the correct solution if we decide to go for it.  IMO a good part
> of the code is already present to support this but as usual the bring-up
> would be considerably slower that the original optimistic expectation.
>
> That said without a prototype all of this is just blablabla :)
>
> Andrea

-- 
akrl@sdf.org