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 :-).
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