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