SRFI Idea: Programmatic REPL/Interaction Environment philipk@xxxxxx (01 Aug 2020 18:04 UTC)
|
Re: SRFI Idea: Programmatic REPL/Interaction Environment
Amirouche Boubekki
(01 Aug 2020 18:10 UTC)
|
Re: SRFI Idea: Programmatic REPL/Interaction Environment
Lassi Kortela
(01 Aug 2020 18:43 UTC)
|
Re: SRFI Idea: Programmatic REPL/Interaction Environment
John Cowan
(01 Aug 2020 19:23 UTC)
|
Re: SRFI Idea: Programmatic REPL/Interaction Environment
Vladimir Nikishkin
(02 Aug 2020 04:26 UTC)
|
LSP, MIT Scheme, notebook programming and REPL rollback
Lassi Kortela
(02 Aug 2020 05:58 UTC)
|
SRFI Idea: Programmatic REPL/Interaction Environment philipk@xxxxxx 31 Jul 2020 18:13 UTC
Hi, I wanted to suggest a SRFI, that standardises the programmatic interaction with Scheme Implementations. The use-cases for this could be: - Developing a Backend-Agnostic Scheme REPL - Making it easier for Editor-extensions like Geiser to support different Scheme implementations, without having to have someone who's familiar with both the internals of said Scheme implementation and Geiser. - Perhaps even static analysis tools? My idea was to specify a stdin/out-based protocol that exchanges S-Expressions in a client-server like setting. So the client could send (complete "fol") to the server, and the server would return a list of symbols/strings, and probably also a status message to make the protocol extensible. I'd argue that the protocol should be as modular as possible, so that implementations don't loose everything if they can't offer all capabilities -- but that should be a familiar concept for Schemers ;) There have already been some cautious discussions on Geiser's[0] bug tracker on the possibilities of this idea. All in all, the idea is still very underdeveloped, and I've never written a SRFI before. That's why I'd like to have some feedback or input from the readers of this mailing list, on ideas, pitfalls or if it's even worth considering such a standardisation effort. [0] https://gitlab.com/emacs-geiser/geiser/-/issues/7 Sincerely, -- Philip K.