Re: Help sought understanding shorthands wrt modules/packages

[Gerd Möllmann]

João Távora <joaotavora@gmail.com> writes:

> So you seem to be somehow lamenting that shorthands is a namespacing
> system! :-)

Hehe :-).  No, I wanted to disagree with Richard saying that there is no
change of semantics at all.  You know--somone being wrong on the
Internet and so :-).

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

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

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

In the case of packages, how to load/execute code from Emacs <= 29 in an
Emacs having packages.  In Emacs <= 29 we find one set of rules, like
allowed symbol name constituents, the behaviour of
intern/intern-soft/symbol-name, when used with symbol-concing, what is a
keyword and so on.  In Emacs with CL packages, some of these rules are
changed, apparently in a way that mostly works, i.e. I can run it with
unchanged packages compiled for 29.

The situation when using shorthands is only insofar different, that I
didn't try to cope with it.  I only have kind of an educated gut
feeling, if something like that exists, especially with
dynamically-bound read-symbol-shorthands that this is, let's say,
difficult.

Or maybe it isn't.  I don't know.  Someone has to invest the time to
find out.

>
> Regardless, if/when CL packages ever make it to core (I hope they do, of
> course), I can't see why someone would want to continue to combine their
> use with shorthands.  The convenience aspect of shorthands would be
> completely dwarfed by CL packages.

Some will, some won't, and some maybe want to use both.  Once it's there
it's there, which means we have to cope with both at the same time.

Ce la vie :-).