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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4