emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help sought understanding shorthands wrt modules/packages


From: Stefan Monnier
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Sun, 30 Oct 2022 10:25:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Gerd Möllmann [2022-10-30 14:48:20] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> The reason why I think shorthands don't address that problem is pretty
>>> simple, according to me again: The underlying one obarray can only
>>> contain one name per symbol at a time.  So, whatever name lands in the
>>
>> I thought CL packages had the same problem: you can't (globally) have
>> two packages with the same name.
>
> That's true, in this case that's a problem with package names.  I guess
> everything having a name can conflict with the same name being used by
> someone else.

Indeed, the standard ELisp coding style is to always type the full
`<PKGNAME>-<LOCAL>` name.  With CL packages, the full names look like
`<PKGNAME>:<LOCAL>` instead but are otherwise similarly forced to
be unique.

The main benefit of CL packages is that you get to skip the `<PKG>:`
prefix, and/or that you can locally use a different (e.g. shorter) prefix.

The shorthands thingy doesn't let you skip the prefix altogether but
does let you locally use shorter prefixes.

> But,
>
> - You can handle it with rename-package.  I've used that in CMUCL, while
>   working its CLOS implementation), to load two versions of PCL in the
>   same image at the same time.

Indeed you get to manipulate your namespace more directly (you can also
add global package aliases).

Another benefit is that there's a clear "inside" and "outside"
of a package, whereas with ELisp's convention there's no immediate
downside for authors to define a few vars&functions outside of their
namespace-prefix.

> - There is an extension "hierarchical packages" which gives packages a
>   tree structure.  It's more or less like with Java packages.  An
>   implementation on top of standard packages isn't very hard.
>   
> https://cmucl.org/docs/cmu-user/html/Introduction-To-Hierarchical-Packages.html

Note that those still need to be globally unique, so it just pushes the
problem a bit further.  To solve it "for real", you can use something
similar but where all your names a "relative".
IIRC https://people.cs.uchicago.edu/~blume/papers/cm-TOPLAS.pdf
is such an example.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]