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 Citrus http://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, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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. > (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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
