> 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.
No, that wouldn't work because the clojure reader is lossy.
What I have in mind is simply not having a clojure reader version, but
only your own "enhanced" version.
One thing that I was thinking is that this might be identical to the
Clojure-produced version but with extra metadata attached to the
structure to indicate "source extras" (like comments and metadata
annotations) and syntax variations (unclosed parens and the like).
This would be nice for you if you're using the reader produced data
for other stuff.
On the other hand, it might be more useful to wrap the structure the
you read in a container (or set of containers) that annotates it. A
simple transform could then "extract" reader compatible version if you
needed it.
> > 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 ?
Not really.
What you have is a Clojure object that you want to explore, but it's
huge, so you don't just want to print it and look at it.
Instead you use the control variables *print-length* and *print-level*
to only print a high-level view of it (into a text control in a swing
app).
Then when you want to go deeper into some part of the structure, you
just click on it and it expands (i.e., *print-level* is incremented,
but only for that part of the structure). Clicking again contracts it.
This is accomplished via callbacks in the pretty printer that allow us
to track where on the screen each part of the logical structure is.
(Simplistically, remember where I enter a particular level of list and
where I exit it.)
> Wow, you gave me a lot of homework ;-)
Just trying to keep you busy :-)
> Well, honestly, 300 to 400 lines per second does not seem very
> performant.
Agreed. Which is why I mentioned the incremental thing.
> 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 ?
Those speeds may be achievable, but even 1-2 seconds will seem slow if
you're doing it all the time. I believe that most systems that do this
use incremental algorithms so as to be O(1) and not O(n) on the file
size.
I do have some places to look for more performance, but I have no idea
how much faster I can make it go before I have to make hard choices.
It seems like every few weeks I take a whack at performance and know
it up an order of magnitude, but who knows how many of those rabbits
(if any) are left in the hat :-).
If you really think about all the cases, pretty printing is reasonably
complex. Add to that my desire to have a pretty printer with flexible
dispatch (which is what would make it work at all for apps like this)
and there's more overhead still. But you can assume that I'll get you
a bunch more performance over time.
Tom
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
