Wow, the enthusiastic response has been really gratifying. Thanks for the kind words; I hope as people try it out that it lives up to the hype.
On Tue, Apr 9, 2013 at 4:47 AM, Laurent PETIT <laurent.pe...@gmail.com>wrote: > Do you have a roadmap for the next releases ? > Initially, my focus will be on gathering feedback from users: making sure it's as stable as I think it is, gathering feature requests. Beyond that, my next objective is to produce a version that can leverage multiple threads. I'm not sure whether the parser really needs to be any faster than it currently is, but Clojure makes it so easy, I might as well offer that. > Of interest to me: > - restartable version ? (probably doable, if internal implementation > uses immutable datastructures) > - incremental version ? (Dunno if that's an easy one, and way beyond > my current programming skills anyway to be able to even judge) > I don't know offhand how doable these are either. I'd need to investigate further. It wasn't really a goal of mine, since Parsley already addresses that space. > - possibility to have transform-map(s) passed as an argument to parse, > so that a collection of views can be applied in parallel and the tree > be "traversed" once ? > Actually, I've already done something very similar to this. You can find it in the "transform" branch of the github page, and you're welcome to try it out and let me know what you think. The tutorial has been updated on that branch to explain how to use that feature, but it basically works the way you'd expect -- you simply pass the transform map as an argument to *parser* (the parser-building function, not the parse function) using the keyword :transform. When you do this, the transforms are done during parse time so the tree is traversed only once. The tradeoff is that parsers with "baked-in transforms" can't be serialized with print-dup. I like the feature, but hesitated to include it. I timed parsers with baked-in transforms against those where the transforms were applied after the fact. On the examples I tried, the time difference was minuscule, presumably because the version with the baked-in transforms ends up applying the transforms to various partial parses along the way. Some of these partial parses are eventually discarded, so applying transforms to those unsuccessful parses means you're doing extra work that potentially cancels out much of the savings from not having to traverse the tree a second time. What this means is that if I include this feature, I have to make sure users clearly understand that it is a tradeoff (possibly better performance, possibly not, depending on context; affects serialization). I like the idea of adding that level of control as to whether the transform is done at parse time or afterwards but, based on my limited experimentation, the benefits didn't seem to outweigh the degree to which it adds to the learning curve. I decided, for now, to make it available as a branch for people to play around with it, and see if it offers any compelling advantages that tip the balance in favor of including it. Your suggestion to make it a keyword argument to the parse function is also possible; I mainly included it in the parser-building function because then the attachment of the transform functions to the parser only needs to be done once, giving it a (tiny) performance boost versus doing it every time in the parse function. > Have you tried some tests to compare performance with e.g. same > grammars in Antlr ? > No, I haven't done back-to-back performance tests. I'm guessing that Antlr would be hard to compete with. Before I began work, I played around with other Clojure parsers to get a feel for their performance, and I believe instaparse to be competitive with those. That statement is based more on feel than precise benchmarks, though. I focused my performance tuning on improving instaparse relative to itself, trying to get parse time to scale linearly with the size of the input, for as many grammars as possible. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
