Re: Proper namespaces in Elisp

[Andrea Corallo]

João Távora <address@hidden> writes:

> On Tue, May 5, 2020 at 11:34 AM Andrea Corallo <address@hidden> wrote
>
>> 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'.
>
> Andrea, this makes no sense.

Hi João, I'm sorry it does make sense deeply to me.

> How is that different
> from Elisp where foo returns 'xxx--aaa and yyy.el checks
> for 'yyy-aaa? Because _that's_ what that program means,
> except, because it is written in a properly namespaced
> Lisp, it does it with fewer chars, is DRY, not WET.

I believe the program wants just to return the symbol 'aaa' and does not
want to bother about other 1000 complications of the CL package system.
And the reason for that is that returning a symbol does *not* create any
name clashing. The name clashing is dangerous only when you resolve the
binding.

> Or don't you think packages should be allowed internal
> symbols at all. Maybe you don't, but that's a question of
> making a package system with the -- IMO quite ill-advised --
> option to auto-exporting everything. It's _not_ an implication
> of the reader-based approach in any way.

I suggest to try to abstrac one second from the implementation point of
view.  This is a low level detail.

> Or did you mean you want an auto-exported,
> self-evaluating,  quick-to-type, one-big-namespace
> qualifier? The keyword package is there for that, as
> you probably know, and that's what everybody uses.
>   _When_  they want those semantics.  So, for me,
> being able to determine the semantics of my program
> (also called "programming") with little typing is a very
> good thing, a very good "implication",  it's exactly the
> power I crave.

I've no doubt you can make it working with CL, guess what they have made
full operating systems with it... and it worked.

I'm just saying that if you look to it from another perspective is very
complex and error prone system and this is an example.

Certainly an experienced CL users can use it because he understands how
this is implemented underneath and has all the knobs.  But is very hard
to understand why it was chosen to behave this way because the only
reason for that is the technical choice and the design was not driven by
ergonomic principles.

That said is just my opinion (arguably shared by a number of people) so
please take it just for what it is.

Andrea

-- 
address@hidden