Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!hplabs!sdcrdcf!darrelj
From: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments
Message-ID: <5036@sdcrdcf.UUCP>
Date: 16 Dec 87 18:19:14 GMT
References: <487@PT.CS.CMU.EDU> <460@cresswell.quintus.UUCP> <13786@think.UUCP>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: Unisys - System Development Group, Santa Monica
Lines: 43

In article <13786@think.UUCP> barmar@sauron.think.com.UUCP (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
>Barry Margolin >barmar@think.com >seismo!think!barmar

No, CL doesn't PREVENT doing it, but it really makes it hard to import
"standard" CL source files into such an environment without loss of
information, mainly because reader treatment of comments, #+ and #- is hard
to preserve for editing and subsequent recreation on output. They can't
always be left inline (OK for source code, maybe, by embedding them in some
form recognized by the interpreter and compiler, but what do you do with
(DEFVAR foo ; this value depends on bar
#+fum '(a b)
#-foobar  ;here is a tricky case
'foobar-absent)
The value of foo had better be the right value, so all the comments and
#+/#- has to be saved elsewhere by LOAD so that editors and file creators
can find and reconstruct them.
Interlisp handles much of what #+ #- do with SELECTQ (like CASE) and a note
that the compiler is guaranteed to optimize away a constant selector
(e.g. (SELECTQ 5 (5 'A)(6 'B) 'C) compiles as 'A ), but this is only in code;
in data one would have to use backquote and ,(SELECTQ ...) etc.
Still another problem is data representation - e.g.
#+hugefloats 3.14159265368979323846
#+tinyfloats 3.14
#+mediumfloat 3.141593
#+incrediblyhugefloats ...
#+incrediblybigarrays #A(jillions of elements ...)
Its easy enough to write a reader which knows enough syntax to read any legal CL
form and throw it away, but if you only have 32-bit floats, how do you
represent a hugefloat for later reconstruction?

There's nothing insurmountable in all this, but it certainly complicates the
world by requiring some kind of shadow database and representations for
objects without supported operators!
-- 
Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449        KI6VY        darrel@CAM.UNISYS.COM   or
...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj