On Thu, May 2, 2013 at 7:19 AM, Max Gonzih wrote:
> Hi, what do you think about dsl version using map?
>
The short answer is that this is already supported. In the github readme,
you'll find a section labeled "Combinators", in which I outline
instaparse's dsl for creating grammars as a map from
Hi, what do you think about dsl version using map?
Nice Idea was proposed here
http://www.reddit.com/r/Clojure/comments/1djbio/growing_a_lanugage_with_clojure_and_instaparse/c9qwv4d
On Tuesday, April 9, 2013 12:41:38 PM UTC+3, puzzler wrote:
>
> On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn >wrot
Interesting, I did not know that.
That's OK if checks do not *guarantee* correctness.
But having 20/80 Pareto principle in mind: if few simple detection technics
will warn about 80% of ambiguous grammars (especially the ones found in
practice), that would be very helpful.
Thanks, Dmitry.
--
--
Thanks for the details. You definitely made the right pragmatic decision. What
you've said pretty much matches what I expected to hear, although I'm
hopeful that the approach can be refined, since it's quite eloquent. Beyond
eloquence, the derivatives approach is also interesting for schema
val
Yes, quite possible. I've added it to the enhancement list on the github
issues page.
On Sat, Apr 13, 2013 at 2:45 AM, David Powell wrote:
>
> Would it be possible to have an option to tag the parse tree with
> meta-data indicating the character offset (or line & column)?
>
> --
> Dave
>
>
--
Would it be possible to have an option to tag the parse tree with meta-data
indicating the character offset (or line & column)?
--
Dave
--
--
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
On Fri, Apr 12, 2013 at 5:55 PM, Brandon Bloom wrote:
> Your readme says "I had difficulty getting his Parsing with Derivatives
> technique to work in a performant way". I was wondering if you could
> please elaborate.
>
> What kind of performance did you achieve?
> How does that compare to the G
Is there not a way to have your parallel parsing cake and eat a
deterministic ordering too? Namely, generate the (undeterministic) list of
possible parses and then parallel mergesort it in some way that imposes a
deterministic total order on distinct parses. Lexicographic would suffice,
I'd expect.
On Fri, Apr 12, 2013 at 1:55 PM, Dmitry Kakurin wrote:
> Here is where my question is coming from:
> If I were to use such parser in production I'd like it to be unambiguous.
> And I'd like to detect ambiguity early, before my software ships/deployed.
> Preferably during build/packaging/deployment
Super cool! Nice work.
Your readme says "I had difficulty getting his Parsing with Derivatives
technique to work in a performant way". I was wondering if you could
please elaborate.
What kind of performance did you achieve?
How does that compare to the GLL parser you implemented?
Did you imple
Thanks Mark,
Here is my understanding and few more questions (please correct me if I'm
missing something).
plus = plus <'+'> num | num
is unambiguous left-associative. It is valid and is guaranteed not to cause
infinite recursion.
plus = num <'+'> plus | num
is unambiguous right-associa
Thank you very much, I'll give it a try!
On Thursday, 11 April 2013 18:12:34 UTC+1, puzzler wrote:
>
> On Thu, Apr 11, 2013 at 7:08 AM, Stathis Sideris
>
> > wrote:
>
>> Thanks, this looks fantastic! Is there any way to include comments in the
>> syntax at all?
>
>
> Last night I started a v1.1
On Thu, Apr 11, 2013 at 7:41 PM, Dmitry Kakurin wrote:
> But your parser rules are somewhat new to me.
> Both variations are accepted:
>
> add = add-sub <'+'> add-sub
> add = mul-div <'+'> add-sub
>
> And in both cases some generated parsers are correct (arithmetically
> speaking :-) ),
Hi Mark,
Brilliant work, thank you!
I was playing with your arithmetic parser from tutorial, and noticed the
following definition for add and sub:
"expr = add-sub
= mul-div | add | sub
add = add-sub <'+'> mul-div
sub = add-sub <'-'> mul-div
...
And I realize now that the ord
On Thu, Apr 11, 2013 at 7:08 AM, Stathis Sideris wrote:
> Thanks, this looks fantastic! Is there any way to include comments in the
> syntax at all?
Last night I started a v1.1 branch to start work on these feature
requests. The first feature I added was, in fact, support for EBNF comment
synt
Sorry for the lack of clarity -- I meant comments about the grammar within
the resource file that describes it. The (str) approach would be good for
embedded grammars in Clojure code, but I'm working with a fairly bulky
grammar which would be better to keep in its own file.
Stathis
On Thursday
I'm not the OP, but if you mean comments within the grammar, sure as long
as "comment" is well defined, and if you mean comments *about* the grammar
within the parser code, how about creating the grammar using (str) with one
string per line, and putting your comments after each line's string?
-Ste
Thanks, this looks fantastic! Is there any way to include comments in the
syntax at all?
Thanks,
Stathis
On Tuesday, 9 April 2013 06:18:39 UTC+1, puzzler wrote:
>
> Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
> The two stand-out features:
>
> 1. Converts standard
On Wed, Apr 10, 2013 at 12:22 AM, sesm wrote:
> Hi Mark,
>
> Amazing stuff, I didn't know, that such general parsing techniques even
> exist!
>
> One minor comment: it would be nice to add direct links to GLL papers and
> https://github.com/epsil/gll github repo to save people some googling
> tim
Wow, an amazing parser with good documentation indeed. I had a go myself at
a parser using a BNF-like syntax as well
(https://github.com/aroemers/crustimoney), but I guess this project
supersedes it by far (although my parser does use programmatic data
structures for the grammar, without using
Hi Mark,
Amazing stuff, I didn't know, that such general parsing techniques even
exist!
One minor comment: it would be nice to add direct links to GLL papers and
https://github.com/epsil/gll github repo to save people some googling time.
--
--
You received this message because you are subscr
On Tue, Apr 9, 2013 at 7:14 AM, Tassilo Horn wrote:
> IMHO, it would be cool if a clojure parser library would use a similar
> format (exploiting clojure data structures beyond lists where they make
> sense), at least internally. Of course, one could still have other
> frontends like for the EBN
Wow, the enthusiastic response has been really gratifying. Thanks for the
kind words; I hope as people try it out that it lives up to the hype.
On Tue, Apr 9, 2013 at 4:47 AM, Laurent PETIT wrote:
> Do you have a roadmap for the next releases ?
>
Initially, my focus will be on gathering feedba
That looks stunning - congrats and thanks!
On Apr 9, 2013, at 1:18 AM, Mark Engelberg wrote:
> Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The
> two stand-out features:
>
> 1. Converts standard EBNF notation for context-free grammars into an
> executable parser.
Mark Engelberg writes:
Hi Mark,
>> (def as-and-bs
>> (parser
>> S = AB* .
>> AB = A B .
>> A = "a" + .
>> B = "b" + .))
>
> I played around with that, but even if you suppress evaluation by
> using a macro, Clojure's reader makes strong assumptions about certain
> symbols.
2013/4/9 Laurent PETIT
> I find this library very exciting. It is incredibly well documented,
> already covers a broad range of use cases, I can't wait for trying it.
>
I concur. Thank you Mark for not letting your users down and writing
the docs.
--
MK
http://github.com/michaelklishin
http:
I find this library very exciting. It is incredibly well documented,
already covers a broad range of use cases, I can't wait for trying it.
There are also a lot of interesting ideas that may pollinate outside
it, I love the cross-pollination capability of open source software !
(i.e. I'd love to s
Thanks for the suggestion. I based the syntax off of EBNF, and hadn't run
across ABNF notation before your link just now. It shouldn't be too hard
to add support for ABNF's repetition syntax and comments. Getting the
semantics of the terminal values to precisely match the ABNF spec seems
like mo
I am not convinced that typing more delimiter characters is a better thing.
The string representation is ... shorter and less error prone.
As Mark said, a string isolates you from the reader which could change
its behavior over time introducing other undesirable side effects like {}
with an uneve
Looks awesome.
Would it be possible to plug in support for the ABNF[1] notation that the
IETF use? Might be useful for implementing standards. Mostly just a
different syntax for repetition, and has support for comments.
[1] http://www.rfc-editor.org/std/std68.txt
--
Dave
--
--
You received
On Tue, Apr 9, 2013 at 2:41 AM, Mark Engelberg wrote:
> What do you think would be gained by making it a macro? From my
> perspective, a macro is essentially just a string that is being processed
> by the Clojure reader (and thus subject to its constraints). If the
> grammar were expressed in th
Am Dienstag, 9. April 2013 11:41:38 UTC+2 schrieb puzzler:
>
> On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn >wrote:
>
>> Nice, but providing the grammar as a plain string looks somewhat
>> unnatural to me. Why not something like this (parser being a macro)?
>>
>> (def as-and-bs
>> (parser
>>
On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn wrote:
> Nice, but providing the grammar as a plain string looks somewhat
> unnatural to me. Why not something like this (parser being a macro)?
>
> (def as-and-bs
> (parser
> S = AB* .
> AB = A B .
> A = "a" + .
> B = "b" + .))
>
Mark Engelberg writes:
Hi Mark,
> Example:
>
> (def as-and-bs
> (parser
> "S = AB*
> AB = A B
> A = 'a'+
> B = 'b'+"))
Nice, but providing the grammar as a plain string looks somewhat
unnatural to me. Why not something like this (parser being a macro)?
(def as-and-bs
(p
Man, this looks like pure gold!
Le mardi 9 avril 2013, Mark Engelberg a écrit :
> Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
> The two stand-out features:
>
> 1. Converts standard EBNF notation for context-free grammars into an
> executable parser. Makes the task of
35 matches
Mail list logo
