Re: Proper namespaces in Elisp

[Andrea Corallo <akrl@sdf.org>]

João Távora <joaotavora@gmail.com> writes:

> On Tue, May 5, 2020 at 3:27 PM Andrea Corallo <akrl@sdf.org> 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?

It is complex what I've explained in the mail with the example, that is
keeping track of every execution paths that can lead to a symbol being
leaked.

The fix is obviously trivial as was (on purpose) the example.  BTW I
don't think the number of characters of a fix tells much about it.

After that would come all the topic of read-time side effects but is a
different one and IMO [2] does a good job on that.

>> 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.

What can I say, I tried to give my opinions, but if you are not
satisfied with them I just apologize.  You have probably over estimated
me.

> (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".

_If_ you allow, I can still think would be more convenient doing A even
if Hyperspec says must do B.

But if you like examples:

You know petrol cars, there is no reason to have electric ones.  If you
read the manual is explained you need to put petrol into them.  We can
then just suggest any proponent of electric cars to just read the manual
of petrol ones to understand how they works.

> [1] https://zenodo.org/record/2648195
> [2] http://www.flownet.com/gat/locales.pdf
>
>
> 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.

I must say this is one the points where your writing sounds is a bit
arrogant.  I'm possibly wrong but I've to say I don't enjoy this
approach and the resulting tone of the conversation.  I don't think it
serves your points.

> 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.

Yes he's trying to show his point of view, that is the system can be
confusing non convenient and error prone, for reasons he's convinced are
valid and he's exposing.

Obviously trying to prove that he is doing on purpose errors, because
every programming language used with no errors just works.  But here
he's *not* trying to prove CL does not work.

> Not exactly categorical, i would say.
>
> So you could have just said "it's not my taste".

Papers just reflect the vision of the authors, this is how it works.
These are not papers describing scientific experiments.

Anyway I don't think we are progressing much so I suggest we just cope
with our disagreement.

Andrea

-- 
akrl@sdf.org