Repository navigation
Proposal: Support grammar aliases. #22
Description
In moderately complex grammars it's fairly common to see duplicate patterns emerge. For example, when matching a dot-separated identifier (eg. foo.bar) the pattern (Ident { "." Ident }) is used repeatedly. This can be handled by a Go type alias implementing the Parseable interface, but that is quite onerous.
I propose adding support for grammar aliases. Here's an example creating and using an Identifier alias:
type Assignment struct {
Name string `@Identifier=(Ident { "." Ident })`
Variable string `"=" @Identifier`
}Reacted by Nikolay Edigaryev and James Harris
Activity
shahms commentedon Feb 12, 2019
Alternatively (or in addition to) just making it easier to go from a grammar string to something which implements
Parseablewould be nice. One way of factoring out the common patterns is to put them in a separate struct and using@@, but that introduces an otherwise unnecessary layer of indirection.Having a facility parallel to
Buildwhich took a "root" instance and grammar string and returned a semi-parser would go a long way, e.g.alecthomas commentedon Feb 14, 2019
That's not a bad idea at all. All it would take would be to add an extra method to the Parser.
alecthomas commentedon Feb 14, 2019
Though it's a bit inconvenient in that, as you say, you end up with a separate struct where you might only need a string or int or whatever.
alecthomas commentedon Jan 22, 2022
I haven't thought of a good API for this yet unfortunately.
alecthomas commentedon Jan 22, 2022
My usual pattern is to pull the field out into a struct. It's a bit uglier for the AST though.
jmalloc commentedon Jan 24, 2024
Is there any accepted approach that I could use to do what @shahms suggested in this comment?
I'm trying to understand the most appropriate way to "jump back" into the normal grammar from within an implementation of
Parseablethat implements precedence climbing as per the example.Pastalikek65 commentedon Aug 9, 2026
Implemented: PR #474 —
participle.Alias(name, grammar)+<name>tag syntax for non-capturing reusable fragments. Captures remain on struct fields; aliases are pattern fragments. Any desire for capturing aliases can be a follow-up (noted in the PR).