Re: Proper namespaces in Elisp

[João Távora]

On Tue, May 5, 2020 at 3:27 PM Andrea Corallo <address@hidden> wrote:
> Yes is how this is worked around that in CL. It works, I'm just saying
> is error prone and unnecessary complex.

What is complex? Understanding how quoting works?
Replacing the quote with a colon?

> No, I'm thinking to one namespace only for symbols *not* for bindings.
> This is not CL or Elisp either.

I don't understand, I admit.  I thought this conversation was about
you telling me why a reader-based system is a bad idea.

(It seems Tom and Stefan have explained that to a point BTW,
it's that internal Emacs features rely on certain names being
interned in the main package. Not necessarily a big problem
IMO, we can discuss that if you want.)

> Thanks for telling me I could learn it.  I'm trying to say that I think
> is unnecessary complex being too low level and that there could be
> another way.  But okay if you prefer I just haven't learned how it
> works.

It's that you insist it should do A when you ask it to do B.
It's like expecting printf("Hello World") to print "Goodbye".

>  https://zenodo.org/record/2648195
>  http://www.flownet.com/gat/locales.pdf

Normally, I'd ignore a lazy paper-drop, but I happened
to know one of them and investigated the other. They are
both short.

So, I'll take the bait:

[1] https://zenodo.org/record/2648195
[2] http://www.flownet.com/gat/locales.pdf

Surely you are aware that [1] is proposing a reader-based system
where symbols are like packages themselves, so that you can
have basically packages inside packages, recursively. It's very
interesting, but incomplete and fraught with difficulties and
shortcomings as admitted by the author himself. But to quote
_that_ as support that plain CL packages are "very complex"?

Also, in [1]  in its section "Problems with CL packages", a very short
section in a very short paper, starts off by admitting that it's
"CL packages are a misunderstood part of CL" [1, p2]. Sounds
familiar, indeed.

Then, the main criticism it levels against them is read-time
side-effects, and points to [2] for justification. We check it out.
[2] show us the unintentional interning of a symbols in the REPL
caused an typo and an unusual way to :USE packages.  Forgets
to mention a REPL is interactive, by definition and that most Lisps
will contain restarts that explain the error and allow you to choose
a solution and continue cleanly after the error. The author also
presents the package version in an unnecessarily verbose way.
Finally that author admits, at the end of the section [2, page 4]
that "This is a matter of taste."  De Gustibus Non Est Disputandum.

Not exactly categorical, i would say.

So you could have just said "it's not my taste".

João




João