Re: Help sought understanding shorthands wrt modules/packages

["João Távora" <joaotavora@gmail.com>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> Anyway, I can't understand how the presence of shorthands can negatively
>> impact CL packages.  If co-existence is complicated (but is it?) it
>> doesn't seem hard to make either shorthands or CL-packages a noop in in
>> files that prefer one of the systems.  For example, the reader can just
>> throw away any shorthand info altogether as soon as it detects that
>> CL:*CURRENT-PACKAGE* (or whatever equivalent you're envisioning) is not
>> the default one.  Or CL:IN-PACKAGE can just error out if it detects that
>> read-symbol-shorthands is non-nil.
>
> If I implied that then I have to apologize.  I meant to convey that

No need to apologize at all :-) 

> (a) I haven't done any experimeent whatsoever with shorthands in
> feature/pkg because I set that delibaretly out-of-scope.  One has to
> draw a line somewhere.

>
> (b) I can't exclude the possibility of non-backwards-compatibility due
> to the use of shorthands.  At least they way I've been doing things in
> the branch.  It's also not proven to be incompatible.  It's unknown.

You can make some tests.  If one goes boom, then we'll know for sure.
If none go boom, well, it's a good indication, but it's very hard to
prove a negative.  I mean, can you really prove Emacs didn't cause the
Hindeburg??

> (c) I might have an idea how do things differently to achieve
> backwards-compatibility.  To what extent that works, or if it works at
> all, I also don't know, and likely won't find out any time soon.
>
>> But even if the read logic didn't do that, and considered the two
>> systems at once, I'm still not sure there would be any ambiguity.
>
> From my point of view, the gist of the matter is
> backwards-compatibility.  That's the pain part.

To be honest, I don't think you should focus effort on this.  Just
declare shorthands out of bounds when CL packages are used, and then go
move on with your project.

IOW proclaim that shorthands only ever worked in the default package and
will continue working only in the default package (the main obarray).
This is absolutely true and saying so is not breaking backward
compatibility.  What's more, no-one will ever request that shorthands
work outside the main package, where they are useless anyway.  It would
solve any compatibility packages.  In practice, this can be as simple as
putting some check for a future CL:*CURRENT-PACKAGE* somewhere in the
current shorthand-consulting reader.

João