Email list hosting service & mailing list manager

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 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.