sirthias / parboiled2

A macro-based PEG parser generator for Scala 2.10+
Other
717 stars 86 forks source link

Allow for explicit rule naming, also for inner rules #50

Closed sirthias closed 10 years ago

sirthias commented 10 years ago

E.g.:

def foo = rule {
  ("abc" ~ oneOrMore('x').named("eks")).named("FOO")
}
cleishm commented 10 years ago

Is this still targeted for the 2.0 release? :)

sirthias commented 10 years ago

No. :)

cleishm commented 10 years ago

Oh well! Any estimate when? I'd love to try parboiled2 for parsing Cypher, but we make pretty extensive use of that right now in order to get the parse errors right.

sirthias commented 10 years ago

Can't you just name the rule methods accordingly? pb2 supports back-ticked rule names (like foo-bar).

cleishm commented 10 years ago

Unsure. I'll try it out.

On Mon, May 26, 2014 at 8:33 AM, Mathias notifications@github.com wrote:

Can't you just name the rule methods accordingly? pb2 supports back-ticked rule names (like foo-bar).

— Reply to this email directly or view it on GitHubhttps://github.com/sirthias/parboiled2/issues/50#issuecomment-44198733 .

sirthias commented 10 years ago

In all the parsing work we've done so far it has paid off to go for small rule methods with pretty clear names. An approach like this should make the explicit rule.named("foo") syntax much less crucial.

cleishm commented 10 years ago

I've considered that, but that wont provide for sharing the same label for multiple rules. For example, here:

https://github.com/neo4j/neo4j/blob/2.1.2/community/cypher/cypher-compiler-2.1/src/main/scala/org/neo4j/cypher/internal/compiler/v2_1/parser/Expressions.scala#L34

There, we use the fairly standard precedence levels for expression parsing. But it would be overwhelming for each and every expression option to be listed when a parse error occurs. So instead we just label them all as "an expression" (which is sensible in the error message, as it comes out as "expected an expression, whitespace, ...").

sirthias commented 10 years ago

Ok, I see. Then it indeed sounds like the explicit naming feature would pay off in your case. It shouldn't be hard to implement.