Re: Proper namespaces in Elisp

[João Távora]

On Mon, May 4, 2020 at 10:59 PM Andrea Corallo <address@hidden> wrote:
>
> João Távora <address@hidden> writes:
>
> > On Mon, May 4, 2020 at 7:30 PM Helmut Eller <address@hidden> wrote:
> >> should be done by the compiler (like lexical scoping).  In other words,
> >> those people would like a mechanism to manage the names of variable
> >> bindings not a mechanism to manage symbols.
> >
> > That last sentence sounds clever but I can't fully grok it. Do you
> > really mean "variable bindings" or just "bindings"? (including function's).
> >
> > On Mon, May 4, 2020 at 7:39 PM Stefan Monnier <address@hidden> wrote:
> >> Richard mentioned his profound dislike of solutions that operate in
> >> the reader.  I'm not sufficiently familiar with Common Lisp's package
> >> system to have a strong opinion on that, but Richard's criticism does
> >> appeal to me (I've been brought up on namespace systems more like
> >> Standard ML's structures).
> >
> > I can't even imagine what a solution that _doesn't_ operate on the reader
> > looks like. Are you talking about form walking macros that walk the
> > forms and switch the short version of names into the long versions
> > and intern everything into the same obarray?  Hmmm.
>
> Namespaces in the read time is a bad idea because it does not affect
> only bindings but effectively all symbols.  I, as many others, do not
> like CL package system too for this reason and all its implications.

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

I think it's a great idea, but I admit I've become so accustomed
to it I never have problems.  I've recently started working with
some CL newbies that caught on pretty fast, too.

What are concrete cases where having a CL-like package
system would cause bugs, confusion, time wasted, etc. Can
you present a hypothetical "horror story"? Oh, but to be fair
you have to present it against a system that also has
namespaces, otherwise it's not fair.

Actually, I can give you an argument against CL packages.
Because Emacs is also missing restarts, a symbol conflict is
hard to fix interactively. Most Lisps will ask the user what do
to when a symbol conflict is found and a good debugger
interface with proper restarts is very useful.

But let's not pretend that any namespacing system is
exempt from symbol conflicts. Indeed in Elisp we deal
with them every day, by inventing contortionist prefixes
and dealing with fun bugs at run-time.

> 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'm not sure either how much this feature is really desired).

Neither am I but If it's not desired, it should be, because it's
hampering Elisp. Did you notice that the request that started
this all, to integrate s.el in Emacs is all bug forgotten and
people are thinking about giving extra names to longstanding
functions?  I for one think that users that like s.el should
use it, I just don't want it polluting and crashing with
everything else. If we had packages or dumb namespacing
that could happen and no-one would get hurt.

João