Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!umbc3!alex
From: alex@umbc3.UMD.EDU (Alex S. Crain)
Newsgroups: comp.lang.lisp
Subject: lisp environments summary
Message-ID: <613@umbc3.UMD.EDU>
Date: Fri, 4-Dec-87 06:30:41 EST
Article-I.D.: umbc3.613
Posted: Fri Dec  4 06:30:41 1987
Date-Received: Wed, 9-Dec-87 02:34:40 EST
Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain)
Organization: University of Maryland, Baltimore County
Lines: 76


	Awile back I posted a request on what makes for a good envirnment.

	I half expected a flood of opinions because of the fierce discussion
over 'tool oriented interfaces', etc, that was in progress. Unfortunately
this group lacks the persistance of say, sports fans, and I guess people 
got bored and went back to work.

	The project started out simple enough, I'm a student for life,
working as a freelance consultant (read unemployed :-)), I love lisp, and
I recently aquired a small unix box real cheap (AT&T 3b1 on sale). I pulled
KCL lisp down in a flash, along with emacs and misc. goodies, hooked it up
and started on a SLR parser generator for school. The failings of lisp under
emacs showed through immediately. The system is a good start, but is 
frustrating and slow to do real work under for reasons that I can't put my 
finger on. As I think that I can stay unemployed for at least another year,
I decided to make this into a serious project, (probably reworking every class
project to fit) and settled in for the long haul.

	Now the problem. Judging from the net discussions, Much remains to be 
done in the way of a workable lisp interface, at least running under UNIX. I
gather that the Sun interface is real good BUT...and short of a symbolics or
explorer full blown lis machine thats as good as it gets. Add the fact that the
suggestions that I got were running from vague to obtuse and getting a grip on
the problem is darn difficult for someone with only about 2yrs of lisp 
programming experiance, all of it on a vax or 3b1 (not enough sun exposer to
really have an opinion).

	SO: The thought for the day...

Every lisp system needs a DEBUGGER that WORKS. KCL comes with a debugger that 
is exactly i step up from worthless, in that you can dump the stack, but not
the tags for the bindings. there are a batch of diff files for it that improve
things alot, but now the error routines are sometimes inacurate...The general
felling that i got was that a full source level debugger is what is desired,
and someone suggested a way to back-step the program. this doesn't seem to 
hard except for recovering old values..I would be interested to know if anyone
had implemented this anywhere.

Multible chains. I like this, because it means distributing the system and I
have limited heap space. But I'm not sure exactly what this means as far as
local/global bindings. (perhaps something similar to UNIX fork(), with common
bindings up to the fork, local after that?)

File system interface. I don't care much for the system access functions 
available (not that there really are any) under CL, and Im not sure that the
directory/file structure is the most natural way to do lisp storage. I have
considered a hypertext type of system, binding functions and symbols with
text comments, probably as an extension to the CL package facility. This would
work well with a source level debugger too...But it needs lots of thought.

The screen/keyboard/mouse relationship to programming. The current GNU/KCL
combination works with several BUTS thrown in, I'm not sure why. It just seems
like there is a better way, althought not an obvious one. What should the
mouse DO exactly? the idea of writing a file and sending it to lisp seems 
wrong, I would want to write my functions and save them when i'm done (I think)
One problem is screen size, im basically limited to 24x80 or my eyes burn out
in 2 hours trying to read teensy little characters. how to put the most info
on the screen has got me stumped. And I don't like the idea of running 
everything through the editor, lots of overhead in that.

This goes on and on, but these are the fundamental problems. right now I'm 
looking for a starting point (after finals anyway), I figure to lay out a
foundation play in january. If anyone has any ideas I would LOVE to hear them,
I would also like to talk with anyone who likes to toss around implementation
concepts. And of cource if anyone needs something to do for a year or too...

							:alex.

alex@umbc3.umd.edu

PS: The debugger enhancements are available from rascal.ics.utexas.edu and are
well worth the installation, even if the are a bit unstable. 



.