From: Sean Engelson
Subject: Re: lisp environments
Date:
Message-ID: <487@PT.CS.CMU.EDU>
With regard to the text vs structure editor controversy: text editors
can simulate structure editors easily (e.g. Emacs-like programmable
ones), but can structure editors simulate text editors?? I don't
think so. Thus, text editors provide a more inclusive model of
editing (i.e. model of computation) than structure editors.
N'est ce pas?
-Sean-
In article <···@PT.CS.CMU.EDU>, ···@SPICE.CS.CMU.EDU (Sean Engelson) writes:
> With regard to the text vs structure editor controversy: text editors
> can simulate structure editors easily (e.g. Emacs-like programmable
> ones), but can structure editors simulate text editors??
Text editors CANNOT simulate structure editors. They can do a rather
feeble job of it. Text editors fall down when context information is
needed in order to decide what to do. For example: a structure editor
can supply different commands, different facilities, for editing
comments and code. For languages with C/Pascal style comments (that can
span multiple lines), this cannot be effectively done with a text
editor. Not, at least, without being willing to search all the way back
to the beginning of the file to see if we're in a comment whenever we
want to do something that's context sensitive. Or you may want to have
different commands when you're editing code than when you're editing
structure declarations.
To answer your question, structure editors can feebly simulate text
editors. A good one can give you the feel of a text editor, in that you
type or delete pretty much anywhere in the code. But a true structure
editor will have problems letting you delete a single parenthesis.
It might be argued that deleting a single parenthesis doesn't make
sense, because that would mean that either the before or after the
deletion, the code was asyntactic. And why would you want asyntactic
code? But this is not a good argument. Sometimes it's quite natural to
look at code as text, and see that what you have is right, except you
really want THAT parenthesis over THERE. Of course, a structure editor
could supply an operation to move a parenthesis around arbitrarily, but
sometimes it really is most natural to allow the program to be
asyntactic for a little while.
What I would like to have is a hybrid editor that maintains both the
structure of what you're editing and the text, and works really hard to
keep them in sync.
For many people, the choice between a structure editor and a text editor
is between laying out their code themselves, and having the system do it
for them. Some take great care in laying out their code, aligning
related bits in adjacent lines. The sort of thing that's very heuristic
and not very algorithmic. The sort of thing that no automatic layout
program could do. For others, the burden is not worth the trouble, and
they would rather settle for the best the system can do.
Some people find the restriction of being syntactically correct all the
time too great. Personally, I find that when I edit code with a text
editor, I almost always have to make several tries at it to get it to
parse properly. Yes, I do have parenthesis balancing and
s-expression-at-a-time movement commands in my text editor (an emacs
lookalike), and that's how I ultimately, painfully, find the missing or
extra parenthesis. But it's just not the same as having my code kept
always syntactically correct. Between never having to worry about
syntax, never having to layout my code, and having commands that rely on
context, I find writing and editing code with Interlisp's SEdit goes
MUCH, MUCH faster than it does with an Emacs-alike.
But that's only my opinion. 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.
I'm not complaining that people use text-based development tools. Only
that it's being made difficult for me to use my preferred tools. (As an
aside I'll point out that in the past, Interlisp-D made
text-editor-based development quite painful. But it's a lot better
now.)
--
-Peter Schachte
···@quintus.uucp
...!sun!quintus!pds
From: Ralph Hyre
Subject: Re: lisp environments (Structure vs. text editors)
Date:
Message-ID: <499@PT.CS.CMU.EDU>
[I have directed followups to comp.editors, where they belong for this
branch of discussion]
In article <···@cresswell.quintus.UUCP> ···@quintus.UUCP (Peter Schachte) writes:
>In article <···@PT.CS.CMU.EDU>, ···@SPICE.CS.CMU.EDU (Sean Engelson) writes:
>> With regard to the text vs structure editor controversy: text editors
>> can simulate structure editors easily (e.g. Emacs-like programmable
>> ones), but can structure editors simulate text editors??
>
>Text editors CANNOT simulate structure editors. They can do a rather
>feeble job of it. Text editors fall down when context information is
>needed in order to decide what to do...
I disagree - a PROGRAMMABLE text editor can do anything you want. This is
because it's programmable. Whether you're happy with the performance or a
particular implementation is a separate, but important issue.
>...For example: a structure editor can supply different commands, different
>facilities, for editing comments and code.
Seems like there's the potential here for moby modefulness. I can't see
why I would want different commands when I edit code compared with comments.
Perhaps some do. More importantly I'm worried about any implementation
where these decisions are hard-coded into the source code of the particular
structure editor in use.
One of the reasons I use emacs and selected emacs-based tools is that
they provide a consistent user-interface when programmed properly.
EMACS is completely programmable in this regard, it's just a matter of
whether you want to have a fixed view of editing or a completely
open (and programmable) one. Depending on how the systems are designed,
the only issue is where you take your performance hit. Under X here,
someone found that GNU emacs used ~22 system calls per keystroke.
My interest is in an pseudo-WYSIWYG editor which gives you the option
of entering/editing text without formatting attributes, then optionally
displaying the text with them. I'm hoping that the Andrew base editor toolkit
will provide facilities for this. This sort of decoupling between editing a
document and a representation of a document could even be used to great
advantage in many environments:
A text editor might keep optional information on parts of speech and
correct spellings, to help produce better documents by allowing
spelling and grammar checking to happen as the text is being entered.
With current technology, the user would need to run one pass of the
spelling checker, another of the grammar checker, then yet another of
the spelling checker to check for grammar/spelling interactions.
(I sometimes type 'then' when I mean 'the'.)
A program code editor might actually be showing you variable names,
statements, and S-expressions while it is really writing the P-code
(or .lbin file) on the fly.
This could result in 'instant' language interpreter facilities and
fast compilers.
[I admit that this might be hairy to program in MockLisp.]
[disclaimer: I've never used a 'structure editor' except for the MacPascal
editor, it kept getting in the way. I have used some EMACS packages (like
Scheme mode) which meet my needs without taking away functionality.]
--
- Ralph W. Hyre, Jr.
Internet: ······@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: ·····@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
--
- Ralph W. Hyre, Jr.
Internet: ······@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: ·····@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
From: J. A. "Biep" Durieux
Subject: Re: Structure vs. text editors
Date:
Message-ID: <961@klipper.cs.vu.nl>
In article <···@PT.CS.CMU.EDU>, ···@SPICE.CS.CMU.EDU (Sean Engelson) writes:
> With regard to the text vs structure editor controversy: text editors
> can simulate structure editors easily (e.g. Emacs-like programmable
> ones), but can structure editors simulate text editors??
In article <···@cresswell.quintus.UUCP>,
···@quintus.UUCP (Peter Schachte) writes:
>Text editors CANNOT simulate structure editors. They can do a rather
>feeble job of it. Text editors fall down when context information is
>needed in order to decide what to do...
In article <···@PT.CS.CMU.EDU> ······@IUS2.CS.CMU.EDU (Ralph Hyre) writes:
>I disagree - a PROGRAMMABLE text editor can do anything you want. This is
>because it's programmable. Whether you're happy with the performance or a
>particular implementation is a separate, but important issue.
Just try, in whatever programmable text editor you want, to edit
the code of the editor itself, implementing new commands, and use
each command in the same session immediately after its code is
edited in.
That's the difference between text and structure editors: whether
the thing which is changing is "the real thing" or a text copy.
--
Biep. (····@cs.vu.nl via mcvax)
To be the question or not to be the question, that is.
From: Rob MacLachlan
Subject: Re: Structure vs. text editors
Date:
Message-ID: <522@PT.CS.CMU.EDU>
I really hate to introduce the light of reason into this debate where most
arguments have been of the form:
X is clearly better than Y (of course I've never used a Y).
...but my passion for truth and justice compels me to set the record
straight.
First, let me point out a terminological problem: most people have been
using the term "structure editor" to mean what I will call a "list structure
editor". This is an editor that represents the object being edited using
the standard list representation. There are various problems associated
with the use of the list representation, and Common Lisp exacerbates these
problems in many ways.
But... It is entirely possible to have a structure editor for Lisp that
uses a richer representation for the program that the default list
representation. Elements of Common Lisp syntax such as "#+", ";" and
package syntax can all be represented in a structured syntax-driven way. A
syntax-directed editor for Lisp could be built using this representation.
Having defined some terms, I will now claim that:
Neither a pure text editor nor a list structure editor provide an
acceptable level of support for Lisp programming.
Of course, all of the text editor proponents have been using editors that
had non-trivial knowledge about Lisp syntax and numberous syntax-directed
commands.
My main objection to a list structure editor is that the standard list
representation is a rather impovrished representation for a program. I am
in the habit of using judiciously chosen vertical whitespace and line breaks
to enhance the readability of my program. I also divide my files into pages
in order to indicate higher level strucure. All this information would be
lost by shoving the program through the reader.
A pure list structure editor also has serious difficulties with comments,
since a comment is an actual component of the evaluated form, and thus must
have a value. This was a problem in the ancient Interlisp structure editor
I once used. I certainly hope that in the state-of-the-art structure
editors being defended here it is possible to introduce comments without
fear of changing the meaning of your program, but any such facility must
involve a step away from a pure list structure editor.
Most people out there like their programming environments. They have
developed various explanations for why their environments are so winning,
but these rationalizations really miss the point. Often a minor, almost
accidental, feature of the environment is used to explain the synergistic
effect of the entire environment. This is definitely the case in the text
v.s. structure editor discussion.
There are two features of Lisp environments that are clearly beneficial:
-- Powerful editing commands that know about Lisp.
-- Interactive, incremental development.
We have been seeing various claims that these features are the sole property
of "structure editors", when in fact neither of these depend on using a list
structure representation.
For example:
>Just try, in whatever programmable text editor you want, to edit the code of
>the editor itself, implementing new commands, and use each command in the
>same session immediately after its code is edited in.
I am one of the primary implementors of Hemlock, a text editor written in
Common Lisp. I have interactively defined commands many times.
>That's the difference between text and structure editors: whether the thing
>which is changing is "the real thing" or a text copy.
This is a red herring. As any Lisp system programmer knows, redefining the
system out from under yourself is a constant problem. It is a clear
advantage to require a confirmation (such as "Compile Defun") that editing
is complete.
It is also not true that "text editors" are forced to consider your program
to be undifferentiated text. Like the EMACS-descended Lisp machine editors,
Hemlock behaves differently depending on the syntactic context. For
example, indentation and justification act differently within comments and
strings. (By EMACS, I mean ITS EMACS, not the bastard Gosmacs.)
In fact, one could make an argument that Zmacs and Hemlock really are
"structure editors", since they incrementally annotate the text
representation with non-trivial syntactic information such as "inside a
comment".
It is also not true that there is any simple relationship between:
-- The editor being written in Lisp.
-- The editor being in the same Lisp environment as the user program.
-- The editor being a list structure editor.
As any Lisp programmer knows, there are obvious advantages to the editor
being written in Lisp. Lisp is such a wonderful language for building
interactive extensible systems that the Unix emacses are built around
mini-lisp implementations.
It would be silly to write a list structure editor in any language other
than Lisp, since the only advantage of the list structure representation is
its naturalness within Lisp. But it would be quite possible to write a
structure editor for Lisp in some other language, and as much as lisp
weenies hate to admit, there would be some advantages.
It is possible to have both structure and text editors that run in the same
environment as the user program: the Interlisp and Lisp machine editors are
examples.
There are also editors written in Lisp that run in a different Lisp process
from the user program. Hemlock supports this style, and it has many
advantages, especially for systems programming. Running in a separate
process doesn't imply inferior interactivity; it just adds a barrier against
the propagation of lossage.
It would be possible to have a list structure editor written in Lisp that
ran in a different process from the user program, but I don't know of any
instances.
It would be more productive if people attempted to determine which features
of their Lisp environments were actually desirable, rather than defending
the implementation strategy and all of the incidental ramifications.
Rob MacLachlan (···@c.cs.cmu.edu)
CMU Common Lisp -- making the world safe for symbolic computing.
From: Jeff Dalton
Subject: Re: Structure vs. text editors
Date:
Message-ID: <217@aiva.ed.ac.uk>
In article <···@PT.CS.CMU.EDU> ···@WB1.CS.CMU.EDU (Rob MacLachlan) writes:
<a clear and reasonable presentation of the issues>
Thank you. The distinction between structure editors (in general) and
list-structure editors should be kept in mind if this discussion continues.
>In fact, one could make an argument that Zmacs and Hemlock really are
>"structure editors", since they incrementally annotate the text
>representation with non-trivial syntactic information such as "inside a
>comment".
I suggested that this might be done in an earlier message and so am
glad to see it's actually been implemented.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
From: Peter Schachte
Subject: Re: lisp environments (Structure vs. text editors)
Date:
Message-ID: <466@cresswell.quintus.UUCP>
<< I tried to post this to comp.editors, but my news system didn't want to >>
In article <···@PT.CS.CMU.EDU>, ······@IUS2.CS.CMU.EDU (Ralph Hyre) writes:
> In article <···@cresswell.quintus.UUCP> ···@quintus.UUCP (Peter Schachte) writes:
> >Text editors CANNOT simulate structure editors. They can do a rather
> >feeble job of it. Text editors fall down when context information is
> >needed in order to decide what to do...
>
> I disagree - a PROGRAMMABLE text editor can do anything you want. This is
> because it's programmable. Whether you're happy with the performance or a
> particular implementation is a separate, but important issue.
When performance gets bad enough, it BECOMES the central issue. If Emacs
spends several seconds determining context for EACH KEYSTROKE, it
becomes unusable.
>
> >...For example: a structure editor can supply different commands, different
> >facilities, for editing comments and code.
> Seems like there's the potential here for moby modefulness. I can't see
> why I would want different commands when I edit code compared with comments.
Don't you switch Emacs to text mode to edit block comments? Line wrap
is so useful there. Better yet, why not have the paragraphs
auto-filled and auto justified while you type, like a word processor?
Make your comments look nice. Use boldface, italics, large headings,
etc. Why not? Just because your tools won't let you?
> ... it's just a matter of
> whether you want to have a fixed view of editing or a completely
> open (and programmable) one.
No, it's a matter of what information you want available to your
programs. There's nothing to say that a structure editor can't be
programmable. A programmable text editor has access to the text of a
program or document, and must parse it in order to determine context.
A structure editor has access to the structure of program or document,
and must unparse (print) it in order to keep the screen up-to-date.
Printing is usually easier than parsing.
>
> [disclaimer: I've never used a 'structure editor' except for the MacPascal
> editor, it kept getting in the way. I have used some EMACS packages (like
> Scheme mode) which meet my needs without taking away functionality.]
Sometime, try SEdit, the new Interlisp structure editor. It still has
some weaknesses, but you might be surprised at how much it can look
like a text editor, and how much advantage it takes of having the
structure around. You might be pleasantly surprised.
--
-Peter Schachte
···@quintus.uucp
...!sun!quintus!pds
From: Barry Margolin
Subject: Re: lisp environments
Date:
Message-ID: <13731@think.UUCP>
I'm posting this for a friend who used to work for Symbolics; his
current employer's policy requires him to post this anonymously:
-----------------
As a maintainer of the Symbolics editor subsystem, I did exactly what
the gentleman from the netherlands posits. I edited the source of the
editor in the editor with immediate modification feedback.
In the Symbolics system, all of the language tools used by the compilers
are available to the rest of the system via *dynamic linking*. The editor
maintains a partial parse of the program in an auxiliary data structure.
It uses event counts to update the parse as the user changes the code.
The partial parse handles errors, so that you can have intermediate states
in which the program is invalid, unlike a structure editor. However,
the partial parse permits features like a command that gives the argument
requirements for a function indicated by the mouse, highlighting of errors,
a mouse click which fetches the source of an indicated function or variable,
a mouse click to place a breakpoint in a program, and a set of commands to
step through compiler errors finding the precise point of error. (the compiler
annotates the actual editor representation if you compile a file from the
editor.) These are only the very tip of the iceberg. Its always depressing
to see a bunch of people yammering back and forth with a religious dispute
instead of finding the compromise position right in front of their
noses.
-----------------
Now to my own comments on the subject. First of all, I have also
edited portions of the Symbolics editor in the editor. Another
posting mentioned that only structure editors can automatically
provide different commands depending on whether you are editing code
or comments, but the Symbolics editor does a great job of this. They
have an "Electric Font Lock" and "Electric Shift Lock" modes, which
automatically change the typein font and case depending on whether you
are typing in code, string literals, or comments, and I don't know
what I'd do without "Auto Fill Lisp Comments" and "Fill Long Comment"
when typing block comments. They don't actually bother changing key
bindings when you are in a comment, but there's no reason they
couldn't.
---
Barry Margolin
Thinking Machines Corp.
······@think.com
seismo!think!barmar
In article <·····@think.UUCP>, ······@think.COM (Barry Margolin) writes:
> I'm posting this for a friend who used to work for Symbolics
> -----------------
> ...The editor
> maintains a partial parse of the program in an auxiliary data structure.
> It uses event counts to update the parse as the user changes the code.
So the Symbolics editor is a text AND structure editor! This approach
seems like it has the best of both worlds. But how partial is partial?
And how long does it take to start up an edit on a fairly large file?
Will it let you know you have a syntax error before you get far afield?
Or do you have to explicitly ASK the system?
> Its always depressing
> to see a bunch of people yammering back and forth with a religious dispute
> instead of finding the compromise position right in front of their
> noses.
I did suggest a compromise in an earlier posting.
--
-Peter Schachte
···@quintus.uucp
...!sun!quintus!pds
From: Barry Margolin
Subject: Re: lisp environments
Date:
Message-ID: <13906@think.UUCP>
In article <···@cresswell.quintus.UUCP> ···@quintus.UUCP (Peter Schachte) writes:
>In article <·····@think.UUCP>, ······@think.COM (Barry Margolin) writes:
>> ...The editor
>> maintains a partial parse of the program in an auxiliary data structure.
>> It uses event counts to update the parse as the user changes the code.
>
>So the Symbolics editor is a text AND structure editor! This approach
>seems like it has the best of both worlds. But how partial is partial?
Well, in the case of Lisp it is pretty simple, because Lisp has very
simple syntax. Each line of the buffer is tagged with the lexical
state at the beginning of the line; this specifies how deeply nested
it is, whether it is in the middle of a string, and the function
definition (or other top-level form) the line is part of. There are
also some heuristics that speed things up, especially useful when the
file isn't totally syntactically correct; for example, the parse state
is reset whenever a line that begins with an open parenthesis is seen,
so that leaving off a close paren will not screw up the parsing of the
rest of the file.
In the case of other languages such as Pascal, C, and Ada, a real
parse tree is maintained, but I don't know much about its
implementation.
>And how long does it take to start up an edit on a fairly large file?
The extra time it takes to parse the buffer is noticeable, but not
intolerable, since it is interleaved with reading the file in from the
file server.
>Will it let you know you have a syntax error before you get far afield?
>Or do you have to explicitly ASK the system?
It generally only does syntax checking when you perform an operation
on a syntactic unit. For example, when you ask to compile the current
Lisp function it checks that the parentheses are balanced within that
definition. There is a command that searches the buffer looking for
unbalanced parentheses. The only automatic syntax check I'm aware of
is done when a Lisp source file is being written out; it checks
parentheses as it goes, and if it notices that they aren't balanced it
asks whether you want to continue writing.
---
Barry Margolin
Thinking Machines Corp.
······@think.com
seismo!think!barmar
From: Barry Margolin
Subject: Re: lisp environments
Date:
Message-ID: <13786@think.UUCP>
In article <···@cresswell.quintus.UUCP> ···@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.
>I'm not complaining that people use text-based development tools. Only
>that it's being made difficult for me to use my preferred tools.
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? And even
if these weren't defined in Common Lisp, who says that the development
system has to be written in portable Lisp; since there's no standard
Common Lisp interface to display terminals, it couldn't be portable if
it were a display editor, and I don't think you were talking about a
line-oriented structure editor. For example, the Scheme standard
doesn't include EVAL or COMPILE, yet there are incore Scheme
development systems (I think most Scheme implementations include EVAL,
it's just not in the standard because it violates the philosophy of
the language).
---
Barry Margolin
Thinking Machines Corp.
······@think.com
seismo!think!barmar
In article <·····@think.UUCP> ······@sauron.think.com.UUCP (Barry Margolin) writes:
>In article <···@cresswell.quintus.UUCP> ···@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 >······@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 ······@CAM.UNISYS.COM or
...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj
From: Stanley T. Shebs
Subject: Re: lisp environments
Date:
Message-ID: <5178X@utah-cs.UUCP>
In article <····@sdcrdcf.UUCP> ·······@sdcrdcf.UUCP (Darrel VanBuer) writes:
>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.
Comments are pretty easy to structureify, takes about two lines of code for
the redefinition of ;. #+/#- slightly harder, because although you can
always represent even bizarre objects by retaining the input form as a
string (which is always possible, eh?), you would still have to write your
own version of a suppressed reader that would return the uninterpreted
goop. CL falls down by not requiring the reader to return the string, but
it doesn't seem like it would be very hard for implementations to provide...
stan shebs
·····@cs.utah.edu
In article <·····@think.UUCP>, ······@think.COM (Barry Margolin) writes:
> In article <···@cresswell.quintus.UUCP> ···@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
···@quintus.uucp
...!sun!quintus!pds
From: Jeff Dalton
Subject: Re: lisp environments
Date:
Message-ID: <213@aiva.ed.ac.uk>
In article <···@cresswell.quintus.UUCP> ···@quintus.UUCP (Peter Schachte) writes:
>Text editors CANNOT simulate structure editors.
They cannot duplicate all features of all structure editors easily, but
they can simulate the basic feature: they can manipulate text in units
defined by language syntax rather than simply as sequences of characters.
Some people find this simulation adequate; others do not.
>Text editors fall down when context information is
>needed in order to decide what to do. For example: a structure editor
>can supply different commands, different facilities, for editing
>comments and code. For languages with C/Pascal style comments (that can
>span multiple lines), this cannot be effectively done with a text
>editor. Not, at least, without being willing to search all the way back
>to the beginning of the file to see if we're in a comment whenever we
>want to do something that's context sensitive.
But they *are* willing to search all the way back to the beginning of
the file. Emacs potentially does this when computing indentation levels.
Of course, most times it needs to search back only a few lines.
Moreover, more efficient methods may be possible. The editor may be able
to keep track of the contexts that apply at various points on the screen
and update this information as changes are made. The screen is relatively
small when a large file is involved, and editors already do interesting
things in order to update the screen efficiently when the file changes.
(Of course, not the same interesting things, but it shows the degree of
effort they're willing to make.)
Whether this is an aspect of structure editors that text editors ought
to emulate is another matter.
>For many people, the choice between a structure editor and a text editor
>is between laying out their code themselves, and having the system do it
>for them. Some take great care in laying out their code, aligning
>related bits in adjacent lines. The sort of thing that's very heuristic
>and not very algorithmic. The sort of thing that no automatic layout
>program could do. For others, the burden is not worth the trouble, and
>they would rather settle for the best the system can do.
It is not necessarily a great burden. Emacs does most of the indentation
for me. In almost all cases, I provide only the line breaks. To me this
makes a great difference for very little effort. Many fully automatic
systems produce results that I find nearly unreadable.
>I find writing and editing code with Interlisp's SEdit goes
>MUCH, MUCH faster than it does with an Emacs-alike.
From what I've seen of SEdit, it is indeed quite nice. Part of the
reason for this is that it is more like Emacs than DEdit was.
The truth is that it's largely a matter of taste -- I do not think either
method is inherently superior. Unfortunately, people made the same claims
for the superiority of structure editors when only DEdit existed. From
this, and from statements like "Emacs is worse than FORTRAN", it seems that
the advocates of structure editing are unwilling to accept that any
opposing views can be valid.
>But that's only my opinion. 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.
I don't see why. You have to provide things like LOAD as well, however.
LOAD just lets you do from files what you can from the keyboard. (Even
the Xerox systems let you omit the structure editor some of the time.)
This is convenient because files are portable. Text is the one format
that everyone can use most easily.
Character macros (which may discard information) may be a greater problem,
but it can't be that they make an in-core, etc. system impossible for
Interlisp has them too.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton