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)
|
Re: SRFI Idea: Programmatic REPL/Interaction Environment Amirouche Boubekki 01 Aug 2020 18:10 UTC
Le sam. 1 août 2020 à 20:04, Philip K. <xxxxxx@posteo.net> a écrit : > > > 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. > Fantastic idea! -- Amirouche ~ https://hyper.dev