Attila Lendvai attila.lendvai@gmail.com writes:
I'd like to be able to load both of them at the same time without conflicts.
OK, that is an argument.
i have a counter argument for too much renaming: the closer the two codebases are to each other, the easier to pull over patches, or ultimately to merge the two projects.
This is an important factor, but it's not my main worry right now. Git is very good at figuring out renames changes and small changes and the volume of contributions to SLIME is not expected to be very high.
My reticence to this particular renaming stems from the fact that the RPC protocol between Emacs and the Lisp process is itself based on the identifier "swank" *and* on its package-designating quality. This is an example of what goes on the > wire
(:emacs-rex (swank:connection-info) nil t 1)
If I blindly rename "swank-">"slynk" in all symbols, packages and parts of symbols, as is being requested, SLY will be immediately locked out of the existing communication protocol.
In practice, this means losing the ability to connect to third party extensions such as SWANKR [1]. It will also, conversely, lose the ability to have an extension like swank-client [2] connect to it.
There are other examples, and even SLIME itself carries swank back-ends for other languages.
In my understanding, asking to rename an external interface resembles asking an HTTP server implementation to rename GET and POST to something else, or asking a Unix implementation to provide grep or sed under different names.
I also don't think arguments of ownership find any kind of provision in SLIME's licensing, but I'm waiting on answers to inquiries that I made to people more knowledgeable in the matter than me. Arguments of authority are also of little or no value to me.
That said, there is the argument of convenience/coexistence that Zach made. I find this argument persuasive, and the "slynk" name particularly elegant.
There is a way to rename "swank" to "slynk" in most places, but implement an indirection that still allows SLY to issue requests in the form "swank:<interface>". Over at the proposed SLYNK side, packages would be nicknamed "SWANK-*" to accept these messages.
These two "tricks" can be packaged in an optional contrib. The contrib would be enabled by default. Users like Zach would need to take care not to ASDF-load "slynk-retro.asd" into an image where "swank.asd" is loaded. Also, before connecting a SLY client to a Lisp where SWANK is laoded (or where it is expected to exist in the future), the `sly-retro' contrib would first need to be deactivated in Emacs with something like
(setq sly-contribs (delete 'sly-retro sly-contribs))
Because SLY will only load contribs' Lisp code on demand (either via ASDF or its own loader) this should be enough to avoid a conflict.
These changes don't seem hard but they don't seem trivial either. Help is welcome.
João Távora
[1]: https://github.com/gigamonkey/swankr [2]: https://github.com/brown/swank-client