Email list hosting service & mailing list manager

SRFI Idea: Programmatic REPL/Interaction Environment Jeronimo Pellegrini (01 Aug 2020 21:12 UTC)
Re: SRFI Idea: Programmatic REPL/Interaction Environment philipk@xxxxxx (01 Aug 2020 21:43 UTC)
Re: SRFI Idea: Programmatic REPL/Interaction Environment Jeronimo Pellegrini (01 Aug 2020 22:26 UTC)

Re: SRFI Idea: Programmatic REPL/Interaction Environment philipk@xxxxxx 01 Aug 2020 21:43 UTC

"Jeronimo Pellegrini - j_p at (via srfi-discuss list)"
<> writes:

> I understand this would require reviewing existing
> protocols (maybe including those not from the Scheme
> world, such as SLIME and LSP)...

But I'd have to look into Geiser's, SLIME's and LSP's architecture (and
their deficiencies) to find out what's missing and what would be nice to

> And I believe it would be important to only require minimum
> support (as Geiser does), since some features may require
> functionality that Scheme implementations don't have.

My idea was to have "rings" of support, so that more flexible
implementations don't get "pulled down" by the simpler ones:

It might look something like this:

- essential features                            (core)
  * checking what parts of the protocol are implemented
- superficial interaction                       (necessary)
  * evaluate an expression
  * load a module
  * expand a macro (unsure about this one)
  * implementation details (along the lines of cond-expand)
- basic system interaction                      (recommended)
  * find definitions
  * basic completion mechanism (symbols)
  * list available modules
  * inspect signatures
- extended system interaction                   (welcome)
  * multi-threaded interaction support
  * value introspection/modification
  * call-stack tracing
  * find referrers

Does this sound about right? It's just a quick brain-dump so there's
certainly something missing/that can be reorganised.

> Also, a SRFI for this would really be nice if it came
> with tests that actually told the implementor what
> he did wrong (see the related Geiser issue [1]).
> Ideally, two test suites, one on the Scheme side, and
> one on the IDE side (the SRFI should be IDE-agnostic,
> but I think it would be great to at least offer an
> Emacs Lisp test suite).

That's also a good point. Come to think of it, this could make it even
easier to just have a compatibility shell script for running Scheme
programs, since the current problem of knowing what parts of the
standard are implemented correctly (think of Guile's faulty cond-expand
or their insistence to call libraries (srfi srfi-27)) to just how to
start the communication protocol. I imagine a "scm" programm, that
finds whatever scheme implementation is available on the system and
initialises it for standardised communication...

But I haven't thought about this enough, so I might be missing

One thing to avoid is unnecessary complexity, for it's own sake of
course, but also to not break with the spirit of the community, that
would deter people from supporting it (ala systemd).

> And maybe debugging support? A hook that would send
> all messages exchanged between IDE and Scheme somewhere?

I feel that it would be better to first lay the ground-work for a
communication-protocol, and some basic functionality. Debugging seems
like a more ambitious project, that would probably be better to specify
as an extension?

The last ring I mentioned above could probably by extended and split
into a debugging feature-set, if it also had breakpoints, step-by-step
evaluation and those kinds of things.

	Philip K.