Re: [ANN] Instaparse 1.1.0

2013-06-16 Thread Zack Maril 
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 
> > 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

2013-06-15 Thread Michał Marczyk 
On 12 June 2013 00:09, Mark Engelberg  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  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

2013-06-15 Thread Michał Marczyk 
On 12 June 2013 00:33, Andy Fingerhut  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

2013-06-15 Thread Michał Marczyk 
On 12 June 2013 15:46, JeremyS  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

2013-06-15 Thread Mark Engelberg 
On Sat, Jun 15, 2013 at 7:21 PM, Zack Maril  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

2013-06-15 Thread Zack Maril 
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  that 
> I have been meaning to be useable from Clojure and ClojureScript. To do so 
> I am using lein-dalap 
> .
>
> 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  helps 
> resolve some of these issues but not all of them. 
> (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  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

2013-06-12 Thread JeremyS 
Hi puzzler,

I have a project  that I 
have been meaning to be useable from Clojure and ClojureScript. To do so I 
am using lein-dalap .

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  helps 
resolve some of these issues but not all of them. 
(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 
> > 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

2013-06-11 Thread Mark Engelberg 
On Tue, Jun 11, 2013 at 3:33 PM, Andy Fingerhut 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).
>

"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

2013-06-11 Thread Mark Engelberg 
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

2013-06-11 Thread Andy Fingerhut 
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 wrote:

> 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 
> 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  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.

Re: [ANN] Instaparse 1.1.0

2013-06-11 Thread Andy Fingerhut 
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 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  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

2013-06-11 Thread Mark Engelberg 
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  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

2013-06-11 Thread JeremyS 
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

2013-06-10 Thread Frantisek Sodomka 
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

2013-06-10 Thread Mark Engelberg 
On Mon, Jun 10, 2013 at 2:57 AM, Frantisek Sodomka wrote:

> 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

2013-06-10 Thread Frantisek Sodomka 
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 
> 
> > 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

2013-06-10 Thread Mark Engelberg 
On Mon, Jun 10, 2013 at 2:13 AM, Frantisek Sodomka 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

2013-06-10 Thread Frantisek Sodomka 
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/c

Re: [ANN] Instaparse 1.1.0

2013-06-10 Thread Frantisek Sodomka 
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

2013-05-14 Thread Mark Engelberg 
On Tue, May 14, 2013 at 6:17 AM, Laurent PETIT wrote:

> 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.

Re: [ANN] Instaparse 1.1.0

2013-05-14 Thread Laurent PETIT 
2013/5/14 JeremyS :
> 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

2013-05-14 Thread JeremyS 
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.

[ANN] Instaparse 1.1.0

2013-05-14 Thread Mark Engelberg 
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.