Here is a link to an article comparing structure editors with other approaches to code editing. Seems apropos to this discussion.
http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Already-Full/Already-Full.html Also, anyone wanting to play with Interlisp's structure editor can do so without too much trouble. Just create a virtual machine (I used vmware player and it works fine), install damn small linux (with a 2.4 kernel) to it and download the software from: ftp://ftp.parc.xerox.com/pub/lfg/ *note that the license prohibits exporting the software to among others, Yugoslavia. So please refrain from travelling back in time and trafficking in the software* (it is a piece of software written inside a lisp development environment which runs among other lisps, Interlisp). Then either install csh (I didn't) or just modify the startup shell script to use the included bash shell. Now, you'll be able to interactively follow along the Interlisp Primer mentioned before in this discussion; specifically section "11.3 Using The List Structure Editor". On Dec 11 2008, 8:08 am, falcon <shahb...@gmail.com> wrote: > Can't say I understood all of it (being a LISP noob) but appreciate > the explanation. > > Does the following fit into the current discussion? > > Barista editor:http://faculty.washington.edu/ajko/barista.shtml > > Barista editor is based on > Citrushttp://faculty.washington.edu/ajko/citrus.shtml > > The citrus page has some _VERY_ cool videos. They are worth watching, > just for entertainment value (entertainment for developers only > though). > > On Dec 11, 9:32 am, "evins.mi...@gmail.com" <evins.mi...@gmail.com> > wrote: > > > On Dec 10, 2:59 pm, falcon <shahb...@gmail.com> 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. > > (Seehttp://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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
