Definition recursion: inline-expression vs argument about fluent HOT 6 CLOSED

@zbraniecki
Indeed very interesting :P
I already knew seanmonstar/l20n.rs project to be a useful resource but I didn't know that some other guy working on a fluent implementation.

My goal is to write a fully tested parser with nom.
I will take a closer look at your project.

Thanks

from fluent.

Thanks for the explanation, it's my first parser so I'm newbie.
I'm gonna dive into this.

from fluent.

Hi @ctjhoa ! I don't have a direct answer to your question, but you may find this interesting - https://github.com/zbraniecki/fluent-rs

I wrote the parser (albeit didn't update it to latest grammar yet!) and some basic foundation for the MessageContext.

It's very early code and I believe the code could use some love from someone with better Rust skills than mine.
Maybe we could join forces? :)

from fluent.

That's awesome! I failed to get a nom parser, and would love to compare my hand written one with nom one to see if there's any value in keeping a handwritten one at all! Can't wait to see yours working! :)

Now, let's get back to the question you asked - @stasm ?

from fluent.

@stasm still no feedback on this?

from fluent.

Thanks for your question and your patience, @ctjhoa. Recursion like this is common in grammars. In this case it allows the call-expression to take inline expressions as positional (not named) arguments:

key = { FUNC("foo") }
key = { FUNC(1) }
key = { FUNC($arg) }
key = { FUNC(iden) }

You'll note that the same recursion is present in the placeable → inline-expression → placeable chain.

As far as I understand it, some top-down parsers have troubles parsing recursive grammars if they use left recursion. Parsing 1 + 2 + 3 with the following grammar would be bad:

sum ::= (sum '+' )? [0-9]

Left recursion makes the parser go infinitely in a loop because the first thing it's trying to parse for a given production is the same production. In the example above the parser starts with a sum and encounters 1, which matches the sum production, so the parser decides to parse another sum; the current production is still 1, which matches the sum etc.. But if we switch the productions around, the parser can handle it no problem:

sum ::= [0-9] ('+' sum)?

Let me know if you have more questions and feel free to close this issue if you agree.

from fluent.