REPL extensions (was Re: [slime-devel] slime-input-stream and REPL extensions)

[Christian Lynbech]

>>>>> "Helmut" == Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

Helmut> Christian Lynbech <christian.lynbech at ericsson.com> writes:
>> Would it be possible to change `slime-input-stream' to become a real
>> stream rather than just a struct?

Helmut> slime-input-stream is a subclass of lisp::lisp-stream, so it a real
Helmut> stream.  (typep *standard-input* 'stream) returns T.

Ahh, I just saw

    (defstruct (slime-input-stream

and missed the inclusion of `string-stream' and jumped to
conclusions. Sorry about that.

>> As a non-stream struct it tends to wreak havoc when some non-slime
>> aware code tries to operate on *standard-input*.
>> 
>> My concrete problem is with Paul Foleys (mycroft at actrix.gen.nz)
>> repl-ext package that allows one to do Allegro style repl commands,
>> and I have come to absolutely love this. This wants to replace the
>> toplevel REPL but does not know how to handle slime-input-streams. The
>> fix is rather simple, but I think it would make slime more robust if
>> it would not be necessary to fix all packages that needs to operate on
>> *standard-input* one by one. 

Helmut> The repl-ext has a function wait-for-input-available that dispatches
Helmut> on the type of the stream, but only fd-stream, synonym-stream, and
Helmut> two-way-stream are covered.  As a workaround you could add a clause
Helmut> (stream nil).

I have added the clause

    (swank::slime-input-stream (swank::sis/misc stream :listen))

to `wait-for-input-available' and that seems to work and appears to me
to be a semi-correct solution.

Helmut> Paul Foleys code assumes that the stream is a fd-stream (or a wrapper
Helmut> around a fd-stream).

I wasn't thinking so much in terms of repl-ext as in terms of the
generic problem. Some slime versions ago I managed to consistently
throw the lisp into a tight loop of errors involving *standard-input*
falling through an etypecase. It might just have been repl-ext blowing
up, but I got the worry that there could be other corners of CMUCL
that would respond badly to the non-fd-stream-ness of
*standard-input*.

Anyway, I fully accept this to be "be fairly difficult to make".

Helmut> The current REPL is partly implement in ELisp and partly in CL.  If we
Helmut> implement the REPL entirely in Lisp we lose some control.  We couldn't
Helmut> tell ordinary output from the prompt or the return value.  I think
Helmut> that isn't desirable.

It was not my intention to change the spirit of the REPL control of
slime, only to integrate the concept of command line interface
commands into slime, however we could do it.

Helmut> We could implement some of the commands in Emacs Lisp, e.g by
Helmut> special-casing input like ":pwd" or perhaps better ",pwd".  Would you
Helmut> like to work on this?

I do not think that hacking the emacs side would be the way to go. An
important part would to allow applications to add new commands that
would be fully integrated into the REPL (including help texts etc).

I think the operation should go something like this:

        (emacs) user types :pwd
        (emacs) slime sends ":pwd" to swank
        (lisp)  swank recognises ":pwd" as a command and look up its defintion
        (lisp)  :pwd definition is executed

I will try to see if I can make any sense out of Pauls hacked up
toplevel and how swank operates its end of the slime repl and see if I
can come with a suggestion.

If somebody has better suggestions of REPL extensions or how to do
this, now is the time to speak up :-)


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)