On Dec 10, 2:59 pm, falcon <[EMAIL PROTECTED]> wrote:
> Could you describe in-core editing a bit more? Sounds interesting.
The canonical structure editor (not "structured editor") is probably
Interlisp-D's SEDIT, or its predecessor DEDIT. (See
http://bitsavers.org/pdf/xerox/interlisp/3102300_interlDprimer_Nov86.pdf
for an archive of Interlisp docs, including docs on SEDIT.) Interlisp
was for a while one of a couple major dialects of Lisp, along with
MACLISP, that were perhaps the most widely used dialects. There were
lots of dialects of lisp in fairly wide use; Common Lisp was intended
to merge the most common idioms in use across a lot of dialects
without losing *too* much of the facilities of any one popular
dialect, but Common Lisp might perhaps resemble MACLISP a little more
than it resembles Interlisp.
Interlisp was the system programming language for the Xerox D-machine
series.
A structure editor, as exemplified by SEDIT, does not operate on text
in a file buffer; instead, it operates on the lisp data structures
represented by the text. When you edit lisp code in emacs, even with a
utility like Paredit, which helps you with the syntactic structure,
you are operating on text characters stored in some sort of array.
There is a connection between the text and what the lisp reader
produces in memory, but you operate on the text, not on the in-memory
lisp objects that are represented by the text.
Structure editors are different: they operate on the in-memory data
structures.
Consider a lisp (or Clojure) list, (a b). This list is a chain of cons
cells, where a cons cell is a pair of pointers. The left pointer
points to the symbol 'a'; the right one points to a second cons cell.
In the second cons cell, the left pointer points to the symbol 'b' and
the right one points to nil.
Now consider the text "(a b)", as seen by some editor. It's a row of
character values: '(', 'a', ' ', 'b', ')'.
The lisp (or Clojure) reader converts that row of characters into the
chain of cons cells described above; the printer converts the chain of
cons cells into the row of characters. There is necessarily a close
correspondence between the text and the in-memory objects, but they
are not the same thing.
Text editors edit text. Structure editors edit the in-memory data
structures.
This might be a good place to repeat that in lisp, and perhaps in
Clojure, I'm not sure, the code is not the text; it's the in-memory
objects. This differs from most programming languages. In most
languages, when you say "source code," you mean text. Strictly
speaking, the text in a ".lisp" text file is not the source code for a
lisp program; it is a text description of lisp source code; the actual
source code is constructed by the lisp reader when it reads the file.
Indeed, given the syntactic rules of Common Lisp, it's possible to
have two very different text files that contain (text specifications
for) exactly the same source code.
Most of the time, this distinction is pretty much academic, because of
the close and necessary correspondence between lisp source code and
its textual representation. There are a few places where the
difference is noticeable, though, and some of them illustrate how a
structure editor differs from a text editor.
For example, consider a circular list: suppose we used RPLACD to make
the nil at the end of (a b) point at the first cons cell, the one
whose left side points to the symbol 'a'. If that value is returned at
the repl (and *print-circle* is not configured to inhibit it) then the
printer will be stuck in an infinite loop printing (a b a b a b a
b....
Now, of course, the circular data structure is not infinite, it's just
circular; it points to itself. But the textual representation is a
little inconvenient for printing such a structure, and indeed, it's
inconvenient for constructing it in the first place (the Common Lisp
reader and printer have a sort of a hack specified in them for these
purposes).
It's quite a bit more convenient to work with such a data structure in
a structure editor, which makes it clear that there isn't really
anything weird or magical about the circular list. It just has an
arrow in the rightmost box of the chain that points to the leftmost
box. No big deal.
Structure editors are not in common use, maybe because, while they're
a valid and maybe cool alternative to text editors for lisp code, it's
not clear how useful they are for other kinds of code. In most
programming languages a lexer and parser construct an abstract syntax
tree from the source code. In lisp, the abstract syntax tree *is* the
source code. That being the case, it makes a lot of sense with lisp to
operate directly on the parse tree. In other languages, not so much.
Some folks love structure editors. I never really used one, but my old
friend and longtime lisp hacker Philip McBride really likes them. I'd
be very glad to see one for Clojure just because it would be fun to
have the option to play around with the code that way.
I don't know whether Rich regards the text of a Clojure program as the
source, or whether he thinks of the source as the data structure
created by the reader when it reads the text. In Common Lisp and some
older dialects, it's pretty clear that the latter is the case.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
