[gambit-list] GUIDE, and changing REPL/reader interface

Derek Peschel dpeschel at eskimo.com
Mon Apr 30 03:36:38 EDT 2007


Hi everybody.  I'll ask the easy question first:  Has anyone compiled GUIDE
on any OS lately?  On Mac OS 10.3 specifically?  (The screenshot I've seen
is from Mac OS X, which is a good sign.)  I'm trying to get it to compile,
I've been running into errors, and it would be nice to know if I have a lot
of work ahead of me or not.  If it's useful, I can post the errors.  But I
was trying to use Qt 4 and I didn't configure Gambit with --enable-guide. 
Now I've reconfigured Gambit and am installing Qt 3, so I'll probably
have more relevant errors soon.

What I really want is a REPL, or editor interface, that knows about Scheme
so it can do parenthesis balancing and symbol lookup, and also talks with
the reader so it can edit any line in a multiline S-exp currently being
read, mark how much of an input line has been read if it contains more than
one S-exp, put whole S-exps in the history instead of lines, and similar
things.

Emacs has some steps in the right direction -- Taylor Campbell's paredit.el
and SLIME being two big ones -- but there are things about Emacs I really
don't like.  And the usual dumb line-based one-way editor-to-LISP interface
won't work very well anyway.  SLIME isn't dumb, but it's complicated and
I haven't seen documentation of Swank as a protocol.  Most other Emacs
libraries seem to be based on comint, so I'd call them dumb.

The solutions seem to be either fancy streams like CLIM's, or changing the
interface between the reader and the editor, perhaps using continuations to
implement coroutines.  The reader needs the usual "process new input" entry
point, but the editor must call the reader and not vice versa.  Also, the
reader needs another "cancel read in progress" (or maybe "cancel read in
progress and process new input") entry point.

Is there any documentation about the current implementation of the TTY
interface, or the GUIDE variant of the same thing?  Is Gambit's abstract
stream definition flexible enough to be extended to do what I want?  Or
does anyone have any examples of combined Scheme/C code that uses
continuations?  With Scheme's first-class continuations, and Gambit's ease
of mixing Scheme and C code (or so I hear), I'm leaning toward the
continuation solution.

Thanks,

-- Derek



More information about the Gambit-list mailing list