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: Gerd Möllmann
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Fri, 11 Nov 2022 14:01:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

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.

If that's not changing semantics, I don't know.  Changing the semantics
of symbols, because of the different meaning of what symbol-name
returns.

> Deciding to use it not use a shorthand is no different from deciding
> to use or not use package qualification for a symbol in CL packages.

I wasn't talking about CL packages at all, just before/after shorthands.

>
> Neither changes the name of a symbol, just the manifestation is
> different. If you force them to be the same thing, then no namespacing
> symbol is possible at all
>
> If you conflate symbol name and symbol designation/manifestation in
> source files , you'll have problems implementing any package system
> (CL, shorthands, whatever) and you confuse people trying to understand
> any Lisp package system, i.e. you confuse this discussion. Let's try
> to avoid that :)

Who's confused?  Anyone?  :-)



reply via email to

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