LSP, MIT Scheme, notebook programming and REPL rollback
Lassi Kortela 02 Aug 2020 05:58 UTC
> Especially since there seem to be at least 4 different protocols on the
> market: geiser, slime, LSP and the one that scheme-mode uses with
> mit-scheme.
Thanks for mentioning the latter two. (LSP = Language Server Protocol,
<https://langserver.org>).
The MIT Scheme thing is probably the one that the "GNU Emacs Interface
" section in the manual is about?
<https://groups.csail.mit.edu/mac/ftpdir/scheme-7.4/doc-html/user_7.html>
We should evaluate these as well.
> Furthermore. I'm not very sure if a repl protocol is the place where
> this should be considered, but some thinking is desperately needed on
> the org-mode/literate computing type of computation.
Good call.
> The thing is, "notebook blocks" are not functions, as they may need
> separate imports, but they are not programs either, because they
> (sometimes) share names.
I'm not familiar with Jupyter notebooks and the like. Conceptually it
sounds like a REPL session that can be rolled back to an earlier point
in time in order to re-evaluate things. Is this right?
REPL rollback is something I've wanted for years. What I mean is typing
something like (remember) or (forget) in the REPL. (forget) would reset
the global bindings to the ones that were active at the time of the last
(remember) checkpoint. So whenever you are happy with the REPL state,
you'd type (remember) to keep it. And when you made a mess with some
experimental code, you could type (forget) to clean it up. There could
also be a stack of chcekpoints: you could pop the stack until you get to
an earlier time you were happy with. But maybe that's overengineering.
A SRFI about REPL rollback would be great. If it can be a useful part of
notebook evaluation as well, so much the better.