Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!teknowledge-vaxc!sri-unix!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments
Message-ID: <476@cresswell.quintus.UUCP>
Date: 17 Dec 87 02:37:35 GMT
References: <487@PT.CS.CMU.EDU> <460@cresswell.quintus.UUCP> <13786@think.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 47
Summary: It's not that I can't write an incore development system IN CL,
	 but that it's hard to write one FOR CL.

In article <13786@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
> >  What the crux of this discussion has been
> >about is how CommonLisp seems to have made an incore, structure-editor
> >based development system very difficult, if not in general impossible.
> How does Common Lisp PREVENT you from using an incore,
> structure-editor-based development system?  What facilities does such
> a system require besides EVAL, SYMBOL-FUNCTION, and COMPILE?

You misunderstand.  I'm not complaining that CommonLisp is not powerful
enough for me to write an incore development system in.  It's plenty
powerful.  I'm complaining that it's hard to write an incore development
system FOR CommonLisp, in any language.

I was concerned about handling features like user-defined read macros
and #+, +-, etc.  But I think I see how to handle them now.  My
remaining problem is with packages.

Let me give an example.  Suppose I have a package ADVENTURE which has
the functions and variables to support an adventure game.  This package
has an external variable CHARGE (excuse me, I mean a variable whose name
is the external SYMBOL CHARGE), indicating how many more turns my
flashlight will last.  Whatever.  I'm developing this module, so I have
the package USER USE ADVENTURE.  Or at least USER IMPORTs
ADVENTURE:CHARGE.

I'm also developing a banking program.  I don't know how I want to
package it yet, so I'm just developing it in USER.  I have a function
called CHARGE which debits an account.  It all works, and I want to
package it now.  So I decide to create the package BANKING and put
everything in it.  I carefully move all the symbols I've defined in USER
into BANKING.  But the catch is that I've also moved CHARGE from
ADVENTURE into BANKING.  And if I now write out ADVENTURE, and later
read it in without having BANKING loaded, the file won't even READ, much
less run.

Here's an even more basic problem.  Package FOO USEs package BAR.  SYM
is a symbol in BAR.  Suppose I write out a file containing SYM with
*PACKAGE* set to FOO.  Since SYM is "visable" in FOO, it is written out
without a package qualification.  Unfortunately, when it is read back
in, it will be put into FOO.  This problem has bitten me several times.
Actually, this problem is not exclusive to incore development systems.
Any CL program that writes out and reads in data can have this problem.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds