On August 1, 2020 6:43:20 PM GMT-03:00, xxxxxx@posteo.net wrote:
>"Jeronimo Pellegrini - j_p at aleph0.info (via srfi-discuss list)"
><xxxxxx@srfi.schemers.org> 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
>have.

I'm willing to help if you agree to work together.

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

*  Error location, debugger interaction?
*  system information? (Easy with SRFI 176)

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

That is interesting!

> but also to not break with the spirit of the community, that
>would deter people from supporting it (ala systemd).

Very good point!

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

I thought of a simple dump functionality, but then, it could have the same fate as the transcript-* procedures, so maybe not a good idea. :)

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

Interacting with steppers would be great!

J.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.