Hi Gerd, I'm there one who implemented shorthands in Emacs, and i sure don't think they are a substitute for CL packages. They can solve some namespacing problems and they can also offer some convenience for library writing (see github.com/joaotavora/beardbolt for an example). But they're infinitely inferior to proper CL packages, especially with the package-local nickname extension. It's "what could be arranged" to use a silly portuguesism. João On Sun, Oct 30, 2022, 06:46 Gerd Möllmann wrote: > Since Richard is swamped with mails, I'd like to try and ask some > questions here. > > To start with---I have no problem understanding the shorthands > mechanism, that's easy enough. (To be honest, I have to admit I don't > like the idea, for reasons I won't go into here, but that's another > story. A mechanism will find its uses, I guess :-). > > My problem is understanding why anyone would think shorthands are an > alternative to or substitute for packages. I mean in principle, and > regardless of packages being Common Lisp packages or any other form of > module system. I simply can't get it. > > So, I guess my first question is: does anyone here think shorthands are > a substitute got packages, and if so could you please share your thought > why, and how one would use them for that? If not, it might also be > helpful to know why not. > > And my second question os: Because I don't get it, I'm considering the > possibility that shorthands are still incomplete, and some features are > missing that would make it a substitute for a module system. Something > that's not documented anywhere, apparently. If so, what is it? Or > where is it described? Or does someone have an idea? You know what I > mean. > > Finally, here's why I don't get the idea: > > According to me, shorthands don't address the problem > packages/modules/namespaces are trying to do deal with _at all_, which > is programming in the large, which means that large programs with many > and diverse contributors suffer from name conflicts. > > 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 > obarray must be unique, as it always was. And this of course leads to > conflicts. Whether or not the unique name can otherwise be used in > abbreviated form or not doesn't change anything in this regard. > > Or am I going nuts and overlooking the obvious? > > > > > > >