On Mon, 2012-03-12 at 21:59 +0900, Andrzej wrote: > On Sun, Mar 11, 2012 at 2:56 AM, Softaddicts > <lprefonta...@softaddicts.ca> wrote: > > About item 1: > > > > The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of > > physical > > memory (magnetic-core memory). > > It had a structural editor. We would change nodes, add/remove child nodes, > > ... > > Interesting. I thought it was only a planned feature, which has never > got implemented.
VMLisp on the IBM Mainframe also was a structure editor. (Mark Wegman, Martin Michaelson, Fred Blair) They were useful because the initial editors on small systems used sed-like commands to edit the text so you did "blind edits" (e.g. c/the/twe/ .... 200 lines changed). Think DOS edlin, TECO, etc. In my first 7 years of programming, the only way to see the text was to type it out but that was hugely wasteful of paper and something you rarely did so "editing" was done "in your head". Structure edits made sure that your edits were properly formed s-expressions. This helped a lot because you no longer had to keep a running count of parens in your head. > > > I still wonder how it could fare compared to the text base approach we are > > used > > to these days. Maybe this is worth an attempt with the current processing > > power > > we have at hand and graphic aids that did not exists et the time. Structure editors took up more memory. Since my big PDP 11/40 had 8k (including the OS), this was a trade-off. With a simple editor files could be up to 4k of text before the next char crashed the system. A more complex editor ate into the program size and caused an earlier crash due to memory being exhausted. > > I think it could work rather well in an education-oriented environment > or in DSLs. I don't think it would be interesting enough to flip > mainstream software engineers on its side, unless it had an Apple > badge on it. ;-) Emacs has paredit which allows s-expression level edits, see paredit-splice-sexp, paredit-forward-slurp-sexp, etc. The http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs has examples. > > I'd rather like to see it working in practice - LISP is all about > about using and manipulating ASTs, yet s-expressions are somewhat > masking this feature (at least to newcomers, which tend to think of > the LISP syntax as of a string of characters with some parentheses > added to it). This leads to thinking about s-expressions as "wholes" where each s-expression at every level does something you could name. This tends to break down a bit as you get closer to the machine. However, at the DSL level structure edits are pretty clean. If you are at a level where you can think in "wholes" then a structure editor might be useful. The VMLisp editor tended to make you think on the syntax level and that is very distracting. You generally don't "see" the parens when writing code since lisp allows one to ignore all syntax issues. Other languages (e.g. C++) require random ';', '{', etc. which forces attention to syntax. Maybe that's why people like IDEs since they tend to provide auto-insertion of delimiters and motion by expression which is a kind of structure editing. Clojure brings back some syntax issues because binding contexts require [ ] pairs and other structured surface syntax protrudes into your attention. Would a Clojure structure editor tend to drift to an IDE? Wouldn't CCW qualify as a structure editor? I believe they have some of paredit's abilities: http://code.google.com/p/counterclockwise Tim Daly -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
