A Roadmap for Lisp Mode Evolution 🚀
cxxxr opened this issue · comments
Problem
With every version update of SLIME, incompatible changes are being made.
Up to version v2.27, it worked fine with Lem, but there seems to be quite a drastic change from around v2.28, and the behavior has changed.
For example, a significant disruptive change in the past can be found at slime/slime@78ad57b.
If not addressed on the client-side, the REPL will hang up.
Also, the output to the REPL has become a bottleneck, and asdf:load-system has become considerably slow.
Besides, there are other areas where behavior has changed due to minor changes in behavior.
As a policy of SLIME, it is strongly integrated with Emacs, and it seems that it does not consider other implementations much.
Continually keeping up with updates to SLIME is too costly and unrealistic, but if left unattended, it will stop working, so constant response is required.
Solution
Fork SLIME
A conceivable solution is to fork SLIME.
Pros
By choosing this method, there is the advantage of not being affected by incompatible changes to SLIME.
In addition, there is already a SLIME implementation in Lem, and there is a track record of comfortable use so far, so it is easy to gradually improve.
Cons
Rarely, the implementation of swank may not work due to the upgrade of the sbcl version.
SLIME may make this correction, but Lem needs to deal with it without receiving the benefits.
Other solutions
Moving to SLY
There is another project called SLY besides SLIME.
This is a branch from SLIME.
However, since SLY also has the potential to make incompatible changes, it is likely not to be a solution.
Reimplement with each version upgrade
There is a method to recreate the implementation of SLIME in Lem each time the version of SLIME goes up and becomes incompatible.
This is too costly to consider.
ToDo
I will summarize the transition procedure below.
This is one idea, so there may be a need to discuss if there are better ways.
Phase 1 ✅
First, fork SLIME v2.27 and place it as a submodule in the Lem repository.
Phase 2 ✅
Then, to avoid a name conflict with the external SLIME of Lem, change the name of the swank package.
Since the same was done in a repository called micros before, it will be named micros (please let me know if you have a better name).
At the same time, the swank client side of Lem also needs to change its name from swank to micros.
The downside of doing this is that swank can no longer be used in Lem.
Phase 3
From here, I will continue developing micros.
I will incorporate the features of SLIME and SLY that I think are better, refer to the functions of symbolics genera, and make it better.
Phase 4
It might parallel Phase 3.
I will integrate with the implementation of LSP for Common Lisp.
Things that can be done with LSP are done with LSP, and features unique to Common Lisp that are not covered by it are done with micros.
The downside of doing this is that swank can no longer be used in Lem.
Umm, is this going to affect the scheme REPL?, AFAIK that back-end language is using swank
is this going to affect the scheme REPL?,
Since lisp-mode and scheme-mode are completely separate codes, I don't think it will affect them.
is this going to affect the scheme REPL?,
Since lisp-mode and scheme-mode are completely separate codes, I don't think it will affect them.
I see, thanks for the clarification 🙌
My understanding is that Sly is better than Slime, so maybe it would be better to fork that?
My understanding is that Sly is better than Slime, so maybe it would be better to fork that?
I would agree on that, I switched from SLIME to Sly in Emacs, and it works remarkably better, maybe is also the case with the CL backend.