Re: Help sought understanding shorthands wrt modules/packages

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 22 Nov 2022 10:01:33 -0800
>>
>> I think there is another drawback of Emacs' prefix based namespace
>> convention: that of longer local (private, non-public, unexported, etc.)
>> names.
>
> Why is that a drawback?  (It's a serious question.)

Thanks for asking.

I have to admit that my answer boils down to familiarity.  I'd like
programming in Emacs Lisp to feel more like the other programming
languages I'm more familiar with.

When I have written Emacs Lisp packages the package name prefixes have
been a bit of a chore to deal with.  I'm happier programming in
languages where the namespace context is a property of a scope, usually
a file level context.  This way, the "current" namespace need not be
re-stated throughout a package's code every time a name is mentioned.

This is a different concern than how code references names names from
other packages.  If I'm writing code that uses something from some other
package, I'm fine stating that other package's name, especially if the
language lets me abbreviate longer package names (usually for the local
file/scope).

I believe the general dislike for having to re-state the associated
package within the package code itself is one reason why people write
packages like https://elpa.gnu.org/packages/nameless.html.

My guess is that avoiding this kind of repetitive verbosity, at least
for the common cases, is what many people want to get out of "Emacs
Packages/Modules".  That is just a guess, though.  I can't really tell
what benefits people actually want when they "it'd be great if Emacs had
CL style packages."

I have to say that, personally, CL style packages didn't "cut it" for me
either.  They did make it easier to have package-private names that were
boilerplate free, but they didn't make it obvious which of my symbols
were exported and which weren't.  That was a property of not of the
symbol name, not of its `defun/defvar', but of whether it appeared in
some export list somewhere else, often in a different file.  I didn't
think that was particularly great, either.