loop, editor

[donc@ISI.EDU (Don Cohen)]

I've been using the "ansi loop" package that I got from the CMU archive.
It compiles and loads with no trouble in CLISP.
It claims to conform to the ansi proposal and so far I have no reason
to doubt it.  I've also installed it in place of the Lucid supplied
loop in lucid CL at work and made a large system with lots of loops
work with only minor change - which I believe is justified by the
standard.  So "no reason to doubt" is not just for lack of trying.
It's also easy to extend.  I'd recommend trying it before
you waste any time trying to modify another one or building your own.

Another topic:

Another thing that I've heard is that people would like to integrate
clisp (or other lisps) with editors on DOS.  My normal mode of using
lisp at work is through gnu emacs and I assume that's what people would
like.  It's what I'd like on DOS if I only had a window system.  (I know
I could use MSwindows - but at the moment we don't have a CLISP interface
to that either, e.g., an implementation of STDWIN.)  One problem is that
I don't have an editor that does that on the PC.  Have any of you actually
tried OEMACS, and does it work in that mode with CLISP?  I probably don't
have room for OEMACS (another reason I'm trying to avoid windows).
I've tried it with EPSILON (the editor I normally use on the PC, from 
Lugaru Software, another EMACS like editor that does allow a shell window) 
(Note also that epsilon is not free) but I can't get CLISP to run in that 
shell.  I haven't yet determined what the cause is.  CLISP starts ok but
the keyboard input gets lost somewhere between epsilon and clisp.
(Each side, of course, suspects the other.)

Another problem is that if your lisp application wants to do graphics etc. 
then you can't do that to the emacs buffer.  That's why you'd need to be
able to create and use other windows from CLISP.
I have been using another partial solution that may interest some of you.
I use the ability of CLISP to call DOS programs to simulate a top level
loop in epsilon.  The top level loop calls epsilon with a command that
I've defined in epsilon.  This puts a transcript file in one window and
an empty input buffer in another (these are two halves of the edit window).
I create a sequence of lisp forms to be evaluated in the input window and
then use another command that I've defined (meta return) to indicate that
I'm done.  This causes the input buffer to be written and returns to lisp.
Lisp evaluates the forms, pretty prints them, along with their results to
the transcript file, and then calls the editor again for more input.
(Standard output is bound to the transcript file as well.)
Any program that does a lot of graphic input and output works fine 
(although the output on the screen does not survive the call to the editor).
Among the limitations are the fact that the debugger does not use the
editor, and the fact that the editor context (what files are open, what
string you last searched for, etc.) is lost between interactions.
Nevertheless, it's pretty reasonable for lots of stuff.

The MSWindows solution seems plausible (at the cost of running windows)
if and when we get a CLISP interface to the windows.

problem is
o Logical pathnames (2/3 done)
o A fancy debugger
o LOOP
o Source code locators
o Who-calls
o ILISP interface (mostly working)

If you are already working on some of these or have thoughts on what is
needed, please let me know.

These are is all straightforward things that can be pretty much just
churned out.  (Well, not the debugger.)  More ambitious projects I would
like to do but will probably never have enough time to get around to
are:

o Threads

Doing a nice thread package ala Genera/Lucid/Allegro involves changing
things at a really basic level, since assumptions the system makes about
global state will not necessarily hold.  And doing it portably without
giving up on using the C stack would be really tricky.

o More compiler analysis

I really like having a compiler that really grovels over the source code
looking for problems ala CMU CL.

    - a "generic" stream capability, where the programmer supplies lisp
    functions to do all the primitive operations on the stream.

The hard parts of this appear to be designing a good, extensible
protocol and dealing with system bootstrapping issues.  Check out the
Gray stream proposal on parcftp for a semi-standardized generic stream
interface for "character" streams.  A complete solution would have to
deal with block-oriented streams, asynchronous events, encapsulation,
etc.  The stream protocol in the CLIM 2.0 spec may be a good guide for
all this that.

--David Gadbois