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. > 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. 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. ;-) 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). > Item 2: > > From what I recall, there were no such confusion in a structural editor. The > confusion > could still be removed by using proper syntax highlights even in a text base > editor. For a graphical/structural representation you'd likely need some sort of meta-data for annotating the source code (e.g. for layout and formatting). These data could then also be used for differentiating between procedure applications and list literals, even if their underlying structures were still the same. > In any case, you would not want to change the underlying representation > otherwise code that processes code would not work anymore or would become > more complex to write. Certainly not in an existing language, unless both representations were perfectly compatible, which is unlikely. As for the macros - that's a valid point. They would have to be redesigned to match against "(apply proc ...)" forms. I don't think that would have to be any more difficult than it is now, though. A new language would likely come with its own macro framework. Andrzej -- 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
