[Slime-devel] SLY, a fork of SLY

[João Távora]

Attila Lendvai <attila.lendvai at 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