Hi Tom, 2009/7/1 Tom Faulhaber <tomfaulha...@gmail.com>: > > Laurent, > > Sounds like a good plan. > > To answer your questions: > >> I'll play with your code. Do you have a first pass over the clojure >> reader to attach other meta information as you go, or do you directly >> consume the clojure data structures the reader passes to you ? > > pprint operates on clojure objects directly and doesn't really > consider where they came from. It has no concept of parsing input at > all. However, output is very flexible, being driven by user-definable > dispatch functions. The architecture is based on the standard Lisp > pretty print architecture called XP. (This is the pretty printer > that's included in Common Lisp, for instance). You might want to look > at the paper "XP. A Common Lisp Pretty Printing System" which is > available at http://dspace.mit.edu/handle/1721.1/6504. The Clojure > implementation is more "clojure-y" but the algorithms and concepts are > substantially the same.
I'll definitely look at it, thanks for the pointer ! > The pretty printer includes two dispatch functions, simple and code. > These are defined in clojure.contrib.pprint.dispatch.clj. You probably > want to skim over those to see the structure of the Clojure > implementation of this stuff. > I've begun to do more complete documentation of the pretty printer and > how to do dispatch here: > http://code.google.com/p/clojure-contrib/wiki/PrettyPrinting > but I've gotten distracted with getting all the doc moved from google > code to github. I should be back to fleshing out that documentation > soon. > Good to know, thanks! > >> If so, >> then certainly there would be the need to have an intermediate >> structure that would be the output of both "clojure reader parsed >> code" and "source code preserving reader parsed code" ? So that the >> rest of the formatting code is decoupled from that ? (But that will >> certainly be lots of changes, and in all parts I guess). > > Not clear to me that you would need the "clojure reader parsed code" > in your implementation since you wouldn't be using that directly and > you could extract relevant information from the source code preserving > reader (like func names, etc.), but obviously you know more about how > you're using the results. Are you suggesting that "clojure reader parsed code" could be first translated back to String and reinjected to the "source code reader" ? Indeed that could simplify final implementation. I don't know what the impact on performance would be, though. > > But yes, you will want to work in terms of an intermediate form that > you can pprint and work on as well. > > Then you would have a modified version of the code-dispatch that > understood the enhanced data structures that were in that version (I > don't think that should be too hard). > > One experiment I've been doing is to build an "Object Explorer" based > on pprint. The thing I added (but that's not totally integrated back > into pprint yet), is callbacks to let you map structure to output > location. I use it there for allowing the user to click on parts of > the object displayed to expand and contract its subobjects. I must look at the code, but is this some sort of implementation of the Builder design pattern ? > I can imagine that in a IDE this could be used to support structural > motion, paredit type things, etc. > > I did a little talk on this here: http://blip.tv/file/2286313 and the > current state of the explorer is on github: > http://github.com/tomfaulhaber/clj-explorer Wow, you gave me a lot of homework ;-) >> >> As far as IDE integration is concerned, i would not bother (at first) >> about incremental thing. I rather intend to always parse the entire >> edited file content (of course if this causes a performance problem, I >> might rethink about it). For performance testing, I've found that >> clojure/core.clj is a good candidate :-) >> > > Yeah, I use core.clj a lot too. I *do* worry about performance here. > pprint currently renders 300-400 lines per second on my machine. It's > getting faster, but I doubt it will ever exceed 10x where it is now > (though I might surprise myself). Well, honestly, 300 to 400 lines per second does not seem very performant. This implies that the reformating of clojure.core would take 10 seconds .... I indeed expected something around "very fast" for a medium size file (300 - 400 lines), and 1 to 2 seconds for something big as clojure.core (but maybe I'm just dreaming). Do you already know where to look for better perf ? > > Keep me up to date on how it's going and feel free to bother me about > whatever. (You can often find me in #clojure as replaca, also.) > Thank you very much, I'll keep you informed. Regards, -- Laurent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
