Re: Help sought understanding shorthands wrt modules/packages

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

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

> João Távora <joaotavora@gmail.com> writes:
>
>> On Fri, Nov 11, 2022, 09:35 Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>>  I don't agree.  Before shorthands, a symbol had one name, after, it can
>>  have many.
>>
>> This is incorrect. You're confusing the text manifestation of a symbol
>> in a Lisp form before it is read (as in CL:READ) with the symbol
>> itself, which has only one name. This didn't and couldn't change with
>> shorthands.
>
> Then let me try to express myself clearer.  (I hoped to get away with
> something more informal.)
>
> Before shorthands there was a 1:1 correspondence between the printed
> representation of a symbol and the symbol you get when reading the
> printed representation.  Symbol-name returned a string that's the
> printed representation.  (And let's please not also consider escaping in
> general, print-escape and print1 vs princ and such.)
>
> After shorthands, there is a printed representation in the code, which
> when read gives you a symbol with a name that can be different from the
> printed representation.  In fact, many printed represenations exist,
> theoretically mapping to the same symbol.

But that's _exactly_ what a namespacing system does: it creates this
indirection.  Which by the way, also enables converse: the _same_
printed representation in two different contexts maping to different
symbols.

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

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.

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.

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.

João