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