Re: [ANN] Instaparse 1.1.0
That is what I meant, should have been clearer. Those reasons make sense. Thank you! -Zack On Saturday, June 15, 2013 10:41:49 PM UTC-4, puzzler wrote: On Sat, Jun 15, 2013 at 7:21 PM, Zack Maril thewi...@gmail.comjavascript: wrote: Why does instaparse not throw errors? Curious about the reasoning behind this design. -Zack I'm not sure what you mean. It does throw errors for certain kinds of invalid grammars and other fatal problems. Perhaps what you're asking is why a string that doesn't fit the grammar will return a failure object. There are several reasons: 1. In my view, it's not really an error -- the parser should return some kind of value that indicates that the string didn't match the parser, and the value should contain information about why it didn't match the parser. It's sort of like choosing to return NaN rather than throwing an error for certain arithmetic ops. 2. The failure object is a simple Clojure map that can be explored, serialized, whatever. (I've chosen to print it somewhat like a thrown error, but it is in fact a value). 3. More consistent when you look at things like the total parse mode, which need to indicate parse failure and return a valid parse simultaneously. You can't do that if the only way to indicate failure is by throwing an error. 4. Makes it possible to chain the output of a parser directly to the transform function. 5. Makes it possible to do things like mapping a parser across a collection of strings to parse. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Why does instaparse not throw errors? Curious about the reasoning behind this design. -Zack On Wednesday, June 12, 2013 9:46:06 AM UTC-4, JeremyS wrote: Hi puzzler, I have a project https://github.com/JeremS/cljss-core/tree/v0.4.0 that I have been meaning to be useable from Clojure and ClojureScript. To do so I am using lein-dalap http://birdseyesoftware.github.io/lein-dalap.docs/ . I totally agree with you about the issues you have foreseen. The protocols aren't exactly the same, the java specific parts would need to be rewritten in cljs, I don't know how much work it would need to have the incremental vector working in cljs since hashing isn't 'embedded' in JavaScript (cljs uses the google closure libraries for that). lein-dalap http://birdseyesoftware.github.io/lein-dalap.docs/ helps resolve some of these issues but not all of them. (cljxhttps://github.com/lynaghk/cljx might also be an alternative) I will totally add a request on github. I know it's a big wish to see instaparse in cljs and I'd love to contribute as best I can. I'd also like to give a little rationale for the cljs adaptation. I am a big fan of LightTable, which I use most of the time now. LT is written in ClojureScript and I can't wait to see the plugin system released in future versions. Using instaparse to extend it would be really neet since it supports ABNF grammar and, as your wiki taught me, ABNF makes for standard grammars that we can find on the internet. It would be nice to exploit directly these grammar in LT using instaparse. Another useful use case is in browser editors for syntaxes like markdown. I have read a blog post considering markdown potentially armful and arguing in favour of the wiki creole syntax. There is an EBNF grammar for creole... Last but very not the least, there are some very inspiring talks from Alan Kay that advocate lisp philosophy of programming, molding the language to your problem and coding in a language that suits the domain of the problem. Instaparse is a great tool to generate our own languages and I am coding some ClojureScript code at the moment so call me biased... :) Cheers, Jeremys On Wednesday, June 12, 2013 12:09:56 AM UTC+2, puzzler wrote: Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even *know* the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschof...@gmail.com wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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.
Re: [ANN] Instaparse 1.1.0
On Sat, Jun 15, 2013 at 7:21 PM, Zack Maril thewitzb...@gmail.com wrote: Why does instaparse not throw errors? Curious about the reasoning behind this design. -Zack I'm not sure what you mean. It does throw errors for certain kinds of invalid grammars and other fatal problems. Perhaps what you're asking is why a string that doesn't fit the grammar will return a failure object. There are several reasons: 1. In my view, it's not really an error -- the parser should return some kind of value that indicates that the string didn't match the parser, and the value should contain information about why it didn't match the parser. It's sort of like choosing to return NaN rather than throwing an error for certain arithmetic ops. 2. The failure object is a simple Clojure map that can be explored, serialized, whatever. (I've chosen to print it somewhat like a thrown error, but it is in fact a value). 3. More consistent when you look at things like the total parse mode, which need to indicate parse failure and return a valid parse simultaneously. You can't do that if the only way to indicate failure is by throwing an error. 4. Makes it possible to chain the output of a parser directly to the transform function. 5. Makes it possible to do things like mapping a parser across a collection of strings to parse. -- -- 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.
Re: [ANN] Instaparse 1.1.0
On 12 June 2013 15:46, JeremyS jschoffen@gmail.com wrote: [...] I don't know how much work it would need to have the incremental vector working in cljs since hashing isn't 'embedded' in JavaScript (cljs uses the google closure libraries for that). ClojureScript uses the Closure library for string hashing and for assigning default hashes / object identities to objects which have no value-based IHash implementation. Data structure hashing works much as it does in Clojure. Cheers, Michał -- -- 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.
Re: [ANN] Instaparse 1.1.0
On 12 June 2013 00:33, Andy Fingerhut andy.finger...@gmail.com wrote: I haven't done anything but think about it during commute time yet, but I had been wondering in how many situations it might be useful to have a string type that was something like Relaxed Radix Binary trees, in that they can be concatenated and substring'd in O(log n) worst case time, and yet substrings would only hold onto references of the parts that they explicitly refer to, and perhaps a little bit more (but not the entire original string). Just a minor note -- RRB trees never hold on to unneeded data (even just a little bit). Agreed that they should be useful in implementing a flexible string type. Cheers, Michał -- -- 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.
Re: [ANN] Instaparse 1.1.0
On 12 June 2013 00:09, Mark Engelberg mark.engelb...@gmail.com wrote: Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: Given how *awesome* it would be for Instaparse to become cross-platform, I'm sure I'm not the only ClojureScript contributor who would gladly help out with any and all porting issues. I'll definitely be watching the GitHub ticket. Cheers, Michał 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even know the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschoffen@gmail.com wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Hi puzzler, I have a project https://github.com/JeremS/cljss-core/tree/v0.4.0 that I have been meaning to be useable from Clojure and ClojureScript. To do so I am using lein-dalap http://birdseyesoftware.github.io/lein-dalap.docs/. I totally agree with you about the issues you have foreseen. The protocols aren't exactly the same, the java specific parts would need to be rewritten in cljs, I don't know how much work it would need to have the incremental vector working in cljs since hashing isn't 'embedded' in JavaScript (cljs uses the google closure libraries for that). lein-dalap http://birdseyesoftware.github.io/lein-dalap.docs/ helps resolve some of these issues but not all of them. (cljxhttps://github.com/lynaghk/cljx might also be an alternative) I will totally add a request on github. I know it's a big wish to see instaparse in cljs and I'd love to contribute as best I can. I'd also like to give a little rationale for the cljs adaptation. I am a big fan of LightTable, which I use most of the time now. LT is written in ClojureScript and I can't wait to see the plugin system released in future versions. Using instaparse to extend it would be really neet since it supports ABNF grammar and, as your wiki taught me, ABNF makes for standard grammars that we can find on the internet. It would be nice to exploit directly these grammar in LT using instaparse. Another useful use case is in browser editors for syntaxes like markdown. I have read a blog post considering markdown potentially armful and arguing in favour of the wiki creole syntax. There is an EBNF grammar for creole... Last but very not the least, there are some very inspiring talks from Alan Kay that advocate lisp philosophy of programming, molding the language to your problem and coding in a language that suits the domain of the problem. Instaparse is a great tool to generate our own languages and I am coding some ClojureScript code at the moment so call me biased... :) Cheers, Jeremys On Wednesday, June 12, 2013 12:09:56 AM UTC+2, puzzler wrote: Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even *know* the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschof...@gmail.comjavascript: wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. On Tuesday, May 14, 2013 10:13:52 AM UTC+2, puzzler wrote: Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The big idea behind instaparse is to make it simple to convert grammars to parsers without needing to know the idiosyncrasies of LL1, LALR, and other esoteric grammar restrictions imposed by most parser generators. When I announced instaparse a little over a month ago, I imagined that I had packed so many features into it, that surely there was nothing more that anyone could possibly want. Oh, how naive I was :) . Within a few days, there were a half-dozen great enhancement ideas posted on the github site. Here are the highlights of the new 1.1.0 release: 1. Support for comments in the grammar. (This was by far the most popular request.) 2. A new front-end for ABNF grammars. ABNF is a syntax popular for carefully defining protocols in formal specs. Instaparse's support for ABNF means that it is a simple copy-paste exercise to turn these specifications into an executable parser. 3. The ability to convert EBNF and ABNF *fragments* into Clojure data structures that can be easily merged with one another and with data structures built by the combinator library. https://github.com/Engelberg/instaparse for full feature list and extensive tutorial. https://github.com/Engelberg/instaparse/blob/master/CHANGES.md for a list of changes since the last version. https://github.com/Engelberg/instaparse/blob/master/docs/ABNF.md for detailed docs about the new ABNF syntax. It seems that whenever instaparse comes up, there is an outcry from people who have a visceral reaction against the notion of building a parser from a *string specification* of a grammar. So I want to be clear up front that instaparse supports *three *input formats that you can freely mix-and-match: EBNF strings, ABNF strings, and Clojure data structures. String input is particularly handy since most grammars are already written down somewhere in one of these two notations, but the data structures are an option if you need them. Instaparse also supports two output formats: hiccup and enlive. This release focused mostly on adding new features; the next version will primarily be another round of performance tuning. If you want to follow along and help test as I try out new optimization strategies, keep an eye on the 1.2.0-SNAPSHOT branch: https://github.com/Engelberg/instaparse/tree/v1.2 Special thanks to Alex Engelberg who implemented the new ABNF input format, and David Powell and Peter Monks who suggested the feature and helped test it. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even *know* the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschoffen@gmail.com wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Mark, I had not heard about Java changing the substring operation from O(1) to O(n). Do you have a link to any further info about this change? I'm guessing that the implementation is changing from the O(1) create a new String object that is a reference to a portion of the original String object to O(n) create a new String object that is a copy of a portion of the original String object? If so, note that it is undesirable in some cases that the O(1) substring operation works as it does, because it prevents the longer string from being GC'ed if it would become garbage, except for the fact that one has created and keeps substrings of it around. One can explicitly call the String constructor to copy the substrings if you want to avoid that behavior, of course, so the O(1) with the O(n) fallback is more flexible in that it lets the developer aware of this behavior choose between them. I haven't done anything but think about it during commute time yet, but I had been wondering in how many situations it might be useful to have a string type that was something like Relaxed Radix Binary trees, in that they can be concatenated and substring'd in O(log n) worst case time, and yet substrings would only hold onto references of the parts that they explicitly refer to, and perhaps a little bit more (but not the entire original string). Andy On Tue, Jun 11, 2013 at 3:09 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even *know* the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschoffen@gmail.com wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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. -- -- 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.
Re: [ANN] Instaparse 1.1.0
And to answer my own question about a reference for this change in behavior, which appears to have been made in Java 7: http://stackoverflow.com/questions/16123446/java-7-string-substring-complexity Andy On Tue, Jun 11, 2013 at 3:33 PM, Andy Fingerhut andy.finger...@gmail.comwrote: Mark, I had not heard about Java changing the substring operation from O(1) to O(n). Do you have a link to any further info about this change? I'm guessing that the implementation is changing from the O(1) create a new String object that is a reference to a portion of the original String object to O(n) create a new String object that is a copy of a portion of the original String object? If so, note that it is undesirable in some cases that the O(1) substring operation works as it does, because it prevents the longer string from being GC'ed if it would become garbage, except for the fact that one has created and keeps substrings of it around. One can explicitly call the String constructor to copy the substrings if you want to avoid that behavior, of course, so the O(1) with the O(n) fallback is more flexible in that it lets the developer aware of this behavior choose between them. I haven't done anything but think about it during commute time yet, but I had been wondering in how many situations it might be useful to have a string type that was something like Relaxed Radix Binary trees, in that they can be concatenated and substring'd in O(log n) worst case time, and yet substrings would only hold onto references of the parts that they explicitly refer to, and perhaps a little bit more (but not the entire original string). Andy On Tue, Jun 11, 2013 at 3:09 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Honestly I hadn't yet given it any thought. Thanks for the interest in having it on Clojurescript. Here are a few issues that come to mind: 1. To achieve performance, I've spent time coding custom data structures that implement various Clojure and Java interfaces. I haven't done much with Clojurescript, but my impression is that the ecosystem of protocols is completely different, so I imagine that could be a pain to transfer over. 2. I don't know much about the performance of Javascript/Clojurescript's underlying data structures. For example, in Java, the substring operation used to be O(1), but recently, much to my dismay, they changed it to O(n). That change was annoying, and it means I'm going to have to rework some code to deal with that, but at least I heard about it and can take it into account. But in Javascript I don't even *know* the performance characteristics of its strings and substring operation. What other Javascript performance gotchas don't I know about? 3. I'm assuming that due to the above, it won't be as simple as just recompiling the code for Clojurescript. I have no idea what's involved with maintaining a code base for the two target languages simultaneously. Sounds non-trivial, although maybe it won't seem so intimidating once things have settled down and I'm not making quite so many performance tweaks and feature enhancements to the code. In any case, please add your request as a github issue, so I don't forget about it. On Tue, Jun 11, 2013 at 8:06 AM, JeremyS jschoffen@gmail.com wrote: Hi Puzzler, I was wondering if you planned to port Instaparse to ClojureScript. I know it's asking a lot, but I am one of those who would love to be able to run it in a browser or in node.js... Cheers, Jeremys. -- -- 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. -- -- 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.
Re: [ANN] Instaparse 1.1.0
Here's another link: http://java-performance.info/changes-to-string-java-1-7-0_06/ -- -- 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.
Re: [ANN] Instaparse 1.1.0
On Tue, Jun 11, 2013 at 3:33 PM, Andy Fingerhut andy.finger...@gmail.comwrote: I haven't done anything but think about it during commute time yet, but I had been wondering in how many situations it might be useful to have a string type that was something like Relaxed Radix Binary trees, in that they can be concatenated and substring'd in O(log n) worst case time, and yet substrings would only hold onto references of the parts that they explicitly refer to, and perhaps a little bit more (but not the entire original string). Ropes have been around for a long time as an alternative to strings, with fast concatenation and splitting. RRB trees might be another, similar route to the same goal. I remember years ago hearing rave reports from people using Cedar (which used ropes as its default string data type), saying it was wonderful to have such a feature-rich string type (well, mainly they were excited about the fast concatenation), so yes, I think it would likely be useful. As I recall, back in 2007, the ICFP Programming Contest was pretty much impossible to solve unless your language had a rope implementation: http://save-endo.cs.uu.nl/ Ropes, like strings, used to be destructive, but I think most new implementations are immutable: Relevant link: http://www.ibm.com/developerworks/library/j-ropes/ -- -- 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.
Re: [ANN] Instaparse 1.1.0
Hello Mark,
I have few suggestions:
1. I was going through the tutorial and comparing EBNF and ABNF grammars.
ABNF adds Bounded Repetition 3*5 A. Is there any chance of adding it also
to EBNF? I don't know, how the syntax would be, but it can be useful at
times.
Repetition of characters can be done inside regular expression. Repetition
of rules can be done also - 3*5 A would be:
S = A A A A? A?
Repetition of 100*120 A is not practical to encode like this anymore. I
know about the combinators:
{:S (rep 100 120 (nt :A))}
and mixing of grammars:
(abnf S = 100*130 A)
but still, it would be nice to be able to do it inside the EBNF string.
Reading through the:
http://en.wikipedia.org/wiki/Ebnf
2. I found that EBNF implements an exception operator -
http://en.wikipedia.org/wiki/Ebnf#Table_of_symbols
used for example like this:
string = '' , { all characters - '' }, '' ;
Negative lookahead can be used instead
string = '' , { !'' all characters }, '' ;
Just wanted to let you know about this difference. I can imagine that there
many modifications of EBNF grammar out there :-)
3. Returning back to the point 1. and reading
http://en.wikipedia.org/wiki/Ebnf#Conventions
There actually is a way, how to express repetitions in EBNF:
aa = A;
bb = 3 * aa, B;
cc = 3 * [aa], C;
dd = {aa}, D;
ee = aa, {aa}, E;
ff = 3 * aa, 3 * [aa], F;
gg = {3 * aa}, G;
Again, don't know if the syntax is optimal. ABNF and regular expressions
define it better, in my opinion.
Thank you for your good work!
Frantisek
On Tuesday, May 14, 2013 10:13:52 AM UTC+2, puzzler wrote:
Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
The big idea behind instaparse is to make it simple to convert grammars to
parsers without needing to know the idiosyncrasies of LL1, LALR, and other
esoteric grammar restrictions imposed by most parser generators.
When I announced instaparse a little over a month ago, I imagined that I
had packed so many features into it, that surely there was nothing more
that anyone could possibly want. Oh, how naive I was :) . Within a few
days, there were a half-dozen great enhancement ideas posted on the github
site.
Here are the highlights of the new 1.1.0 release:
1. Support for comments in the grammar. (This was by far the most popular
request.)
2. A new front-end for ABNF grammars. ABNF is a syntax popular for
carefully defining protocols in formal specs. Instaparse's support for
ABNF means that it is a simple copy-paste exercise to turn these
specifications into an executable parser.
3. The ability to convert EBNF and ABNF *fragments* into Clojure data
structures that can be easily merged with one another and with data
structures built by the combinator library.
https://github.com/Engelberg/instaparse for full feature list and
extensive tutorial.
https://github.com/Engelberg/instaparse/blob/master/CHANGES.md for a list
of changes since the last version.
https://github.com/Engelberg/instaparse/blob/master/docs/ABNF.md for
detailed docs about the new ABNF syntax.
It seems that whenever instaparse comes up, there is an outcry from people
who have a visceral reaction against the notion of building a parser from a
*string specification* of a grammar. So I want to be clear up front that
instaparse supports *three *input formats that you can freely
mix-and-match: EBNF strings, ABNF strings, and Clojure data structures.
String input is particularly handy since most grammars are already written
down somewhere in one of these two notations, but the data structures are
an option if you need them. Instaparse also supports two output formats:
hiccup and enlive.
This release focused mostly on adding new features; the next version will
primarily be another round of performance tuning. If you want to follow
along and help test as I try out new optimization strategies, keep an eye
on the 1.2.0-SNAPSHOT branch:
https://github.com/Engelberg/instaparse/tree/v1.2
Special thanks to Alex Engelberg who implemented the new ABNF input
format, and David Powell and Peter Monks who suggested the feature and
helped test it.
--
--
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.
Re: [ANN] Instaparse 1.1.0
EBNF syntax for bounded repetition could be just simply A 3*5 and these are
equal:
A? is A*1
A+ is A1*
A* is A0*
Frantisek
On Monday, June 10, 2013 11:04:52 AM UTC+2, Frantisek Sodomka wrote:
Hello Mark,
I have few suggestions:
1. I was going through the tutorial and comparing EBNF and ABNF grammars.
ABNF adds Bounded Repetition 3*5 A. Is there any chance of adding it also
to EBNF? I don't know, how the syntax would be, but it can be useful at
times.
Repetition of characters can be done inside regular expression. Repetition
of rules can be done also - 3*5 A would be:
S = A A A A? A?
Repetition of 100*120 A is not practical to encode like this anymore. I
know about the combinators:
{:S (rep 100 120 (nt :A))}
and mixing of grammars:
(abnf S = 100*130 A)
but still, it would be nice to be able to do it inside the EBNF string.
Reading through the:
http://en.wikipedia.org/wiki/Ebnf
2. I found that EBNF implements an exception operator -
http://en.wikipedia.org/wiki/Ebnf#Table_of_symbols
used for example like this:
string = '' , { all characters - '' }, '' ;
Negative lookahead can be used instead
string = '' , { !'' all characters }, '' ;
Just wanted to let you know about this difference. I can imagine that
there many modifications of EBNF grammar out there :-)
3. Returning back to the point 1. and reading
http://en.wikipedia.org/wiki/Ebnf#Conventions
There actually is a way, how to express repetitions in EBNF:
aa = A;
bb = 3 * aa, B;
cc = 3 * [aa], C;
dd = {aa}, D;
ee = aa, {aa}, E;
ff = 3 * aa, 3 * [aa], F;
gg = {3 * aa}, G;
Again, don't know if the syntax is optimal. ABNF and regular expressions
define it better, in my opinion.
Thank you for your good work!
Frantisek
On Tuesday, May 14, 2013 10:13:52 AM UTC+2, puzzler wrote:
Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
The big idea behind instaparse is to make it simple to convert grammars to
parsers without needing to know the idiosyncrasies of LL1, LALR, and other
esoteric grammar restrictions imposed by most parser generators.
When I announced instaparse a little over a month ago, I imagined that I
had packed so many features into it, that surely there was nothing more
that anyone could possibly want. Oh, how naive I was :) . Within a few
days, there were a half-dozen great enhancement ideas posted on the github
site.
Here are the highlights of the new 1.1.0 release:
1. Support for comments in the grammar. (This was by far the most
popular request.)
2. A new front-end for ABNF grammars. ABNF is a syntax popular for
carefully defining protocols in formal specs. Instaparse's support for
ABNF means that it is a simple copy-paste exercise to turn these
specifications into an executable parser.
3. The ability to convert EBNF and ABNF *fragments* into Clojure data
structures that can be easily merged with one another and with data
structures built by the combinator library.
https://github.com/Engelberg/instaparse for full feature list and
extensive tutorial.
https://github.com/Engelberg/instaparse/blob/master/CHANGES.md for a
list of changes since the last version.
https://github.com/Engelberg/instaparse/blob/master/docs/ABNF.md for
detailed docs about the new ABNF syntax.
It seems that whenever instaparse comes up, there is an outcry from
people who have a visceral reaction against the notion of building a parser
from a *string specification* of a grammar. So I want to be clear up
front that instaparse supports *three *input formats that you can freely
mix-and-match: EBNF strings, ABNF strings, and Clojure data structures.
String input is particularly handy since most grammars are already written
down somewhere in one of these two notations, but the data structures are
an option if you need them. Instaparse also supports two output formats:
hiccup and enlive.
This release focused mostly on adding new features; the next version will
primarily be another round of performance tuning. If you want to follow
along and help test as I try out new optimization strategies, keep an eye
on the 1.2.0-SNAPSHOT branch:
https://github.com/Engelberg/instaparse/tree/v1.2
Special thanks to Alex Engelberg who implemented the new ABNF input
format, and David Powell and Peter Monks who suggested the feature and
helped test it.
--
--
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
Re: [ANN] Instaparse 1.1.0
On Mon, Jun 10, 2013 at 2:13 AM, Frantisek Sodomka fsodo...@gmail.comwrote: EBNF syntax for bounded repetition could be just simply A 3*5 and these are equal: A? is A*1 A+ is A1* A* is A0* Right now, in the EBNF syntax, numbers are valid non-terminal identifiers. So for example, rather than S = A B+, you could do 1 = 2 3+. I thought this might be useful for programmatically generated grammars. Adding a bounded repetition operator to EBNF is certainly possible, but the most obvious syntaxes would eliminate the use of numbers as identifiers. Have you actually encountered a real example where you wished for the large bounded repetition, or is this just a theoretical question? Even in the ABNF examples I've seen (which has the bounded repetition option), most instances of repetition correspond to the standard + * and ? operators. I've seen the exception operator listed on a couple of tables, but have never seen it in use, and didn't come across a clear explanation of its semantics. Can you point me to a fuller description of what it does? -- -- 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.
Re: [ANN] Instaparse 1.1.0
Large bounded repetition is a theoretical question. My use case requires to
ensure repetition of only small number of digits - one digit, two digits
and similar. I would use bounded repetition to ensure the needed number of
digits. Yes, different workarounds will work for me, so it is not a
pressing problem.
Googling the exception operator:
http://avisynth.org/mediawiki/User:Gzarkadas/EBNF
Exception The effect is the logical negation of the rule
following. For example -a becomes ? all characters not equal to a ?.
They use it here:
stringliteral =
quote , { -quote } , quote | tripleqouote , { -tripleqouote } ,
tripleqouote
;
So it is something like everything else than. In Instaparse we would
define exception + set S = !'a' #'.'
They just define exception S = -'a'
On Monday, June 10, 2013 11:26:13 AM UTC+2, puzzler wrote:
On Mon, Jun 10, 2013 at 2:13 AM, Frantisek Sodomka
fsod...@gmail.comjavascript:
wrote:
EBNF syntax for bounded repetition could be just simply A 3*5 and these
are equal:
A? is A*1
A+ is A1*
A* is A0*
Right now, in the EBNF syntax, numbers are valid non-terminal
identifiers. So for example, rather than S = A B+, you could do 1 = 2
3+. I thought this might be useful for programmatically generated
grammars. Adding a bounded repetition operator to EBNF is certainly
possible, but the most obvious syntaxes would eliminate the use of numbers
as identifiers.
Have you actually encountered a real example where you wished for the
large bounded repetition, or is this just a theoretical question? Even in
the ABNF examples I've seen (which has the bounded repetition option), most
instances of repetition correspond to the standard + * and ? operators.
I've seen the exception operator listed on a couple of tables, but have
never seen it in use, and didn't come across a clear explanation of its
semantics. Can you point me to a fuller description of what it does?
--
--
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.
Re: [ANN] Instaparse 1.1.0
On Mon, Jun 10, 2013 at 2:57 AM, Frantisek Sodomka fsodo...@gmail.comwrote: Googling the exception operator: http://avisynth.org/mediawiki/User:Gzarkadas/EBNF Exception The effect is the logical negation of the rule following. For example -a becomes ? all characters not equal to a ?. Yeah, that's still not clear to me. It says it is the logical negation of a rule but then goes on to say that it negates the characters. What does -ab mean? If you're just negating characters, in instaparse you can just use regex's capability to express negative character classes. So, for example, every character but an a is most clearly and efficiently expressed as #[^a]. http://www.regular-expressions.info/charclass.html -- -- 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.
Re: [ANN] Instaparse 1.1.0
I am just curious, not requesting this feature :-) How to represent negation in BNF? http://stackoverflow.com/questions/10922352/how-to-represent-negation-in-bnf http://pythonhosted.org/modgrammar/libref.html modgrammar.EXCEPT(grammar, exc_grammar, **kwargs) Match grammar, but only if it does not also match exception_grammar. (This is equivalent to the - (exception) operator in EBNF) EXCEPT() grammars can also be created by combining other grammars in python expressions using the except operator (-). Note: In many cases there are more efficient ways to design a particular grammar than using this construct. It is provided mostly for full EBNF compatibility. modgrammar.EXCEPT function would do difference or complement mentioned on stackoverflow. Seems like a sane approach - we know the set we are excluding from. Concerning negating characters - yes, it is quite tricky. I don't yet how to define it... Does S = -ab ab c matches abc or just c? Dne pondělí, 10. června 2013 12:10:00 UTC+2 puzzler napsal(a): Yeah, that's still not clear to me. It says it is the logical negation of a rule but then goes on to say that it negates the characters. What does -ab mean? If you're just negating characters, in instaparse you can just use regex's capability to express negative character classes. So, for example, every character but an a is most clearly and efficiently expressed as #[^a]. http://www.regular-expressions.info/charclass.html -- -- 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.
Re: [ANN] Instaparse 1.1.0
Hi Puzzler, Instaparse seems to be a wonderful piece of software congrats ! I haven't had the time to test it yet but it's on the top of my to do list. Cheers Jeremy. PS This is kind of a fan boy message but congratulations really seem to be in order nonetheless :) On Tuesday, May 14, 2013 10:13:52 AM UTC+2, puzzler wrote: Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The big idea behind instaparse is to make it simple to convert grammars to parsers without needing to know the idiosyncrasies of LL1, LALR, and other esoteric grammar restrictions imposed by most parser generators. When I announced instaparse a little over a month ago, I imagined that I had packed so many features into it, that surely there was nothing more that anyone could possibly want. Oh, how naive I was :) . Within a few days, there were a half-dozen great enhancement ideas posted on the github site. Here are the highlights of the new 1.1.0 release: 1. Support for comments in the grammar. (This was by far the most popular request.) 2. A new front-end for ABNF grammars. ABNF is a syntax popular for carefully defining protocols in formal specs. Instaparse's support for ABNF means that it is a simple copy-paste exercise to turn these specifications into an executable parser. 3. The ability to convert EBNF and ABNF *fragments* into Clojure data structures that can be easily merged with one another and with data structures built by the combinator library. https://github.com/Engelberg/instaparse for full feature list and extensive tutorial. https://github.com/Engelberg/instaparse/blob/master/CHANGES.md for a list of changes since the last version. https://github.com/Engelberg/instaparse/blob/master/docs/ABNF.md for detailed docs about the new ABNF syntax. It seems that whenever instaparse comes up, there is an outcry from people who have a visceral reaction against the notion of building a parser from a *string specification* of a grammar. So I want to be clear up front that instaparse supports *three *input formats that you can freely mix-and-match: EBNF strings, ABNF strings, and Clojure data structures. String input is particularly handy since most grammars are already written down somewhere in one of these two notations, but the data structures are an option if you need them. Instaparse also supports two output formats: hiccup and enlive. This release focused mostly on adding new features; the next version will primarily be another round of performance tuning. If you want to follow along and help test as I try out new optimization strategies, keep an eye on the 1.2.0-SNAPSHOT branch: https://github.com/Engelberg/instaparse/tree/v1.2 Special thanks to Alex Engelberg who implemented the new ABNF input format, and David Powell and Peter Monks who suggested the feature and helped test it. -- -- 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.
Re: [ANN] Instaparse 1.1.0
2013/5/14 JeremyS jschoffen@gmail.com: Hi Puzzler, Instaparse seems to be a wonderful piece of software congrats ! I haven't had the time to test it yet but it's on the top of my to do list. Cheers Jeremy. PS This is kind of a fan boy message but congratulations really seem to be in order nonetheless :) Yeah, even if I don't use any of his projects atm, I'm also becoming a fan boy of Mark. Mark, the combined qualities of the code, the documentation, the communication, is inspiring ! Cheers, -- Laurent On Tuesday, May 14, 2013 10:13:52 AM UTC+2, puzzler wrote: Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The big idea behind instaparse is to make it simple to convert grammars to parsers without needing to know the idiosyncrasies of LL1, LALR, and other esoteric grammar restrictions imposed by most parser generators. When I announced instaparse a little over a month ago, I imagined that I had packed so many features into it, that surely there was nothing more that anyone could possibly want. Oh, how naive I was :) . Within a few days, there were a half-dozen great enhancement ideas posted on the github site. Here are the highlights of the new 1.1.0 release: 1. Support for comments in the grammar. (This was by far the most popular request.) 2. A new front-end for ABNF grammars. ABNF is a syntax popular for carefully defining protocols in formal specs. Instaparse's support for ABNF means that it is a simple copy-paste exercise to turn these specifications into an executable parser. 3. The ability to convert EBNF and ABNF fragments into Clojure data structures that can be easily merged with one another and with data structures built by the combinator library. https://github.com/Engelberg/instaparse for full feature list and extensive tutorial. https://github.com/Engelberg/instaparse/blob/master/CHANGES.md for a list of changes since the last version. https://github.com/Engelberg/instaparse/blob/master/docs/ABNF.md for detailed docs about the new ABNF syntax. It seems that whenever instaparse comes up, there is an outcry from people who have a visceral reaction against the notion of building a parser from a string specification of a grammar. So I want to be clear up front that instaparse supports three input formats that you can freely mix-and-match: EBNF strings, ABNF strings, and Clojure data structures. String input is particularly handy since most grammars are already written down somewhere in one of these two notations, but the data structures are an option if you need them. Instaparse also supports two output formats: hiccup and enlive. This release focused mostly on adding new features; the next version will primarily be another round of performance tuning. If you want to follow along and help test as I try out new optimization strategies, keep an eye on the 1.2.0-SNAPSHOT branch: https://github.com/Engelberg/instaparse/tree/v1.2 Special thanks to Alex Engelberg who implemented the new ABNF input format, and David Powell and Peter Monks who suggested the feature and helped test it. -- -- 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. -- -- 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.
Re: [ANN] Instaparse 1.1.0
On Tue, May 14, 2013 at 6:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Mark, the combined qualities of the code, the documentation, the communication, is inspiring ! Aw shucks. I'm blushing. Thanks guys. --Mark -- -- 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.
