Seems awkward to construct ASTs from parol actions

[Techcable]

Hi! It seems very awkward to construct an AST from parol's semantic actions trait :(

As a particular example, take a look at the json example. We have the AST node that's all nice and strongly-typed.

However, converting from the parse tree -> AST require you manually push/pop from an untyped stack, which seems extremely awkward and error-prone too.

Other parser generators in rust seem to have similar problems. This is especially the case for ones that enforce a separation between grammar and semantic actions (in particular pest)

Parser generators that do not enforce this separation between actions/grammars can get around this problem, by building up the AST directly in the grammar file. This is what lalrpop does to build ASTs

I am not suggesting we include actions in the grammar. That seems ugly. I am also not suggesting we provide a way to automatically map between parse trees and ASTs. That is a landmine of complexit.

What would be really nice is if we had some sort of macro that could help map users build up their AST. Maybe it could auto-implement the grammar actions trait?

The Problem of Grammar Transformations

Part of what makes implementing this sort of macro difficult is the grammar transformations. Right now, the actions trait is based on the expanded grammar, not the original grammar.

This means that the originally specified Object item in the json grammar, expands to four sub-items in the expanded grammar.

While the user would intuitively expect to write one semantic action for an Object, when in fact they have to write four actions based around the expanded grammar :(

I'm not a parser expert by any means, and I totally understand grammar transformations are necessary to deal with left-recursion and all that stuff.

However, I still think it would be amazing if we could have semantic actions more in line with the original grammar/parse tree, and not based on the expanded/transformer grammar.

This would make going from parol -> AST much easier, regardless of whether they do it by hand or by some sort of macro.

Antlr

Again, I would like to reiterate that I am not a parser expert. I barely understand the basics of DFA transitions, let alone this whole LL(*) magic that Antlr is doing 😉

However, I think the antlr could be maybe (a little bit) of an API inspiration for how to design the visitor traits.

Here's a gist of ANTLR's json visitor/parser.

Notice two things:

1. The parse tree is based on the original grammar, not internal transformations
2. The parse tree is horribly ugly and clunky, because Java doesn't have enums

As far as I can tell, parol's parse tree is dynamically typed. Maybe in addition to hiding internal transformations, we can (somehow) make the parse tree statically typed?

This is kind of me just babbling/complaining about usability (and comparison to ANTLR), I'm not sure how actionable this is :)

[Techcable]

Looking more at the parse-tree angle, it might be okay that the parse-tree is untyped.

By default, that's what tree-sitter and rust-analyser do.

rust-analyser even has a special generator (ungrammar) for generating concrete syntax trees (here's a blog post on it).

Maybe we could add integration with this by default or something?

To quote the blog post:

In typical parser generators, something similar can be achieved by generating both the parser and the syntax tree from the same grammar. This works to some extent, but has an inherent problem that the shape of the tree you want for the programmatic API, and the shape of the grammar you need to implement the parser are often different. “Technical” transformations like left-recursion elimination don’t affect the language described by the grammar, but completely change the shape of the parse tree. In contrast, ungrammar focuses solely on the second task, which radically reduces the complexity of the grammar.

[jsinger67]

Hi Techcable,

Thank you very much for your elaborate contribution to our discussion.

First I would like to state that parol makes no assumptions on how the user handles the grammar processing. It only demands that the user's item implements the UserActionTrait (see the parse function in parol's runtime) that the parser generator has created for it. So the example in the json_parser is what it is, just an example. Especially the type of AST stack used on client side can by defined independently. Actually even no serious AST handling is necessary as seen in the refactored list example.

I'm convinced that this loose coupling is one of the strengths of parol.

Nevertheless I totally agree with you in the sense that the problem of constructing ASTs is solely left to the user and he or she is a bit left alone here. No support from parol currently exist in this case and things get even worse because parol expects the user to deal with its transformed grammar.

This is really a downside of parol right now.

So I'm glad that you pointed me to ANTLR. Actually some fundamentals of parol were inspired by ANTLR. Notably the use of DFAs to find the production to chose next was influenced by ANTLR although implemented in parols own way.

But there are some crucial differences between ANTLR and parol most important the kind of code both generate. While ANTLR generates recursive functions parol actually generates data for a push-down automaton (PDA).

ANTLR doesn't need to deal with grammar transformation and due to the similarity between the grammar description and the generated parser's source it quasi entails the ability to provide the Visitor pattern.

The downside of ANTRL's code generation is that the user could write files that the parser would crash with stack overflows 😉. parol's parsers can't suffer serious damage from stack overflows because their ParseStack is located on the heap.

Anyway I think we should carefully think over some kind of improvement here.

Several things are imaginable:

• A kind of visitor pattern at input grammar's level of abstraction, maybe as an additional trait generated automatically. The big challenge here is to keep the input grammar's abstraction level. We have to mark user level non-terminals to be able to distinct them from non-terminals (and productions) introduced by grammar transformation. And then we need to provide the results from the supplementary productions to their "calling" ones somehow. To make this work we need schemes on how to map things like {x} to Vec<x> or [x] to Option<x> etc. where x is the result of those inner or supplementary productions. This is sort of the inverse operation of the grammar transformation applied at parser generation time. We could therefore perhaps introduce pseudo instructions into productions.
• Supporting semantic actions at non-terminal level, i.e. in the json_parser example you gave above there would be only one action for Object. This could possibly reduce the irritation induced by the transformed grammar version. But on the other hand this could move complexity into the user's implementation of semantic actions. I currently doubt that this is useful.
• Giving the semantic actions additional generic parameters and/or a generic return type, simply to aid flexibility.
• Providing supporting macros to deal with matching the ParseTreeStackEntries. But this is actually a detail of implementation the at user's side. It would be feasible thought if parol established a kind of standard or best practice on how to implement the grammar processing in semantic actions. An interesting point anyway.
• ...

[jsinger67]

Let me start thinking a bit loud 😁

Let's say we have the following simple list grammar

%start List
%title "A possibly empty comma separated list of integers"
%comment "No trailing comma is allowed."

%%

List: [Num {"," Num}];
Num: "0|[1-9][0-9]*";

It has an Optional and a Repetition construct in it and seems to be a good starting point.
This will generate the following expanded grammar.

%start List
%title "A simple comma separated list of integers"
%comment "No trailing comma is allowed."

%%

/* 0 */ List: Num ListList;
/* 1 */ ListList: "," Num ListList;
/* 2 */ ListList: ;
/* 3 */ List: ;
/* 4 */ Num: "0|[1-9][0-9]*";

The trait with the user actions will currently look like this:

pub trait ListGrammarTrait {
    // ...
    fn list_0(
        &mut self, _num_0: &ParseTreeStackEntry, _list_list_1: &ParseTreeStackEntry,
        _parse_tree: &Tree<ParseTreeType>) -> Result<()> { 
        Ok(())
    }

    fn list_list_1(
        &mut self, _comma_0: &ParseTreeStackEntry, _num_1: &ParseTreeStackEntry,
        _list_list_2: &ParseTreeStackEntry, _parse_tree: &Tree<ParseTreeType>) -> Result<()> {
        Ok(())
    }

    fn list_list_2(&mut self, _parse_tree: &Tree<ParseTreeType>) -> Result<()> {
        Ok(())
    }

    fn list_3(&mut self, _parse_tree: &Tree<ParseTreeType>) -> Result<()> {
        Ok(())
    }
    // ...
}

But what we actually could want is this (this is only a sketch):

pub trait ListGrammarTrait {
    // ...

    /// Semantic action for:
    ///
    /// List: [Num {"," Num}];
    ///
    fn list(
        &mut self,
        // The right-hand side of the production he wrote in its input grammar contains preprocessed
        // aggregations already applied. 
        _rhs: Option<(&ParseTreeStackEntry, Vec<(&ParseTreeStackEntry, &ParseTreeStackEntry)>)>,
        _parse_tree: &Tree<ParseTreeType>) -> Result<()> {
        Ok(())
    }
    // ...
}

I think this is not perfect but would achieve big advantages. The user is saved from tediously
picking up collection items one by one.

The right-hand side of the List production

List: [Num {"," Num}];

is interpreted as an Option of a tuple. The elements of the tuple are a grammar symbol followed by a
collection of two-element tuples.

So we have an adhoc scheme on how to map EBNF constructs on structures of grammar symbols:

• Sequences -> Tuples
• Groups -> Inner tuples
• Optional Expressions -> Option<x>
• Repetition Expressions -> Vec<x>

In a next step we can improve that even more by adding type names to grammar symbols within the
input grammar.

%start List
%title "A possibly empty comma separated list of integers"
%comment "No trailing comma is allowed."

%%

List: [Num {"," Num}];
Num<NumType>: "0|[1-9][0-9]*";

which could effect in this action

/// Semantic action for:
///
/// List: [Num {"," Num}];
///
fn list(
    &mut self,
    // The right-hand side of the production he wrote in its input grammar contains preprocessed
    // aggregations already applied. 
    _rhs:
    Option<(&ParseTreeStackEntry<NumType>,
        Vec<(&ParseTreeStackEntry<&str>, &ParseTreeStackEntry<NumType>)>)>,
    _parse_tree: &Tree<ParseTreeType>) -> Result<()> {
    Ok(())
}

The only constraint on the associated type would be that it is visible to the Rust compiler (can be
solved by some kind of %use instruction) and that it implements the From<&str> trait.

I wouldn't forgo the ParseTreeStackEntry completely because it provides access to the scanned
token and to the parse tree if one needs to navigate that somehow.

Currently I have a lot of ideas but I'm not sure if everything is feasible.

First I'm curious about your opinion.

[Techcable]

In a next step we can improve that even more by adding type names to grammar symbols within the
input grammar.

_rhs:

Option<(&ParseTreeStackEntry<NumType>,
    Vec<(&ParseTreeStackEntry<&str>, &ParseTreeStackEntry<NumType>)>)>,
_parse_tree: &Tree<ParseTreeType>) -> Result<()> {

I would hold back on a strongly typed parse tree for now. It seems like a lot of complexity (although it's super cool 😄 ).

There seems to be an increasing trend to use an untyped syntax tree as a base, then write wrapper code later. Both tree-sitter and rust-analyzer do this.

rust-analyser is an especially interesting case, because then they wrote an ungrammar utility to[automatically generate typed wrappers on top of their existing (untyped) syntax tree.

From the blog post introducing it.

Ungrammar is a notation to concisely describe the structure of the syntax tree, which can be used by a code generator to build an API in the target language. If you’ve heard about ASDL, ungrammar is ASDL for concrete syntax trees.

As explained in the blog post, having this separation often results in simpler (typed) parse trees than a traditional grammar using ANTLR/Yacc.

As a particular example, the full ungrammar description for the rust-analyser parse tree (used in production) is a little over 600 lines, while the corresponding ANTLR grammar for Rust is well over 1300 lines.

I think we should probably stay with untyped parse trees for now, and in the future, we could do some sort of automatic integration with ungrammar. Maybe auto-generate a default "ungrammar" if the user hasn't specified one?

[jsinger67]

I thought about how to provide "user level semantic actions".
I think this could be achieved by carefully auto-implementing the semantic actions of the expanded grammar. In the 'top level' semantic actions the real user level semantic actions (one for each alternative) with aggregated data can be called.

The auto-implementation must include an inner Grammar struct that auto-implements the expanded grammar's actions and calls the user level semantic actions at appropriate points. You can think of this Grammar implementation as an adapter between the expanded grammar and the original grammar.

The advantage is that it seems possible to keep the parol-runtime library untouched.
From user's side there are no more semantic action from the expanded grammar to implement. Only the actions for the original input grammar are exposed to him for possible implementation.

This is not exactly what you suggested. But it goes into the right direction, I think.

I will start a test implementation for this soon where the auto-generated parts are still manually created by me, I think.
You will have the chance to review it then.

[jsinger67]

Actually it turns out that implementing this is hard.

Simply because you to have know something about how the grammar transformation can be reversed and how expanded productions contribute to their "parent" productions, i.e. how types should be composed together.

As in my example above the type

Option<(&ParseTreeStackEntry, Vec<(&ParseTreeStackEntry, &ParseTreeStackEntry)>)>

is visually comprehensible but hard to construct without "meta" information.

Since intermediate types of this kind have to be put onto a parse stack the implementation needs to create a concrete enum type with appropriate variants for each of those intermediate types.

For example in a preceding step you would encounter a (comma, Num) pair translated as

(&ParseTreeStackEntry, &ParseTreeStackEntry)

which must be pushed onto the parse stack too.

At the end you need something like this:

enum ListGrammarAutoItem {
    // -------------------------------------------------------------------------
    // Types needed to call user level semantic actions
    // -------------------------------------------------------------------------


    // Type of argument 0 of list0 semantic action
    List0Arg0(
        Option<(
            &ParseTreeStackEntry,
            Vec<(&ParseTreeStackEntry, &ParseTreeStackEntry)>,
        )>,
    ),
    // Type of argument 0 of num0 semantic action
    Num0Arg0(&ParseTreeStackEntry),

    // -------------------------------------------------------------------------
    // Types needed for intermediate steps
    // -------------------------------------------------------------------------

    // Type produced by production 1 of expanded grammar
    P1(&ParseTreeStackEntry, &ParseTreeStackEntry)

    ...
}

The next problem is that you can't share ParseTreeStackEntry references between the parse tree of the LLKParser and the ParseStack of the "AutoGrammar" item easily and you have to carefully think over live-times when you don't want to clone a lot.

It will certainly work but I see increasing complexity coming from such an approach. This is exactly what you already anticipated.

Currently I'm investigating all the other information sources you gave me, especially ungrammar and how its ideas could help to find a more elegant solution. CST to AST mapping looks promising because it could provide a mechanism to automate such a task of auto-generation.

When we need to derive some sort of "meta" information, why not try to derive a CST to AST mapping to back auto-generation?

Parse tree operations

Another idea that probably goes in this direction could be to transform the parse tree itself during parsing. In Lelek I used such an approach. There I inserted parse tree operations into productions during grammar transformation. Those instructions are later processed by the parser at the time of parse tree construction. An example is explained here. This can be seen as a kind of keyhole optimization based on information available at the time of grammar transformation. The flattened parse tree for a list can be easier processed because it can be presented with all children appearing at the same tree level and handled in one semantic action.

This what a parse tree from a list of numbers looks in parol

And this is what Lelek produces finally.

Both grammars here are slightly different and parol is more verbose but the difference of the tree structure becomes obvious.

[jsinger67]

I think I'll refrain from such things like Parse Tree Operations now.

What I'm currently concentrating on is extracting information about the data flow between the productions of the expanded grammar via inner item stack and from the expanded grammar to the original one.

This could turn out to lead to a similar solution like ungrammar but I first like to explore it on my own 😉.

Based on this I hope to be able to auto-generate the inner (i.e. expanded) semantic actions including the calls of the outer (i.e. user) actions and the data types needed for the inner item stack.

I think I will give up the try to share data from the LLKParser with the inner grammar (its parse tree is not really of interest for the end user; also to store node ids outside the tree is discouraged by the maintainer of the id_tree crate). The only thing I would reference is the parsed text which is likely a great portion of memory consumption. The lifetime of it is already handled correctly in parol-runtime.

Also I struggle for better naming.

The expanded grammar is planned to be an internal implementation detail. Thus I tend to use the word 'inner' or 'internal' in relation with it.
The original input grammar would then be called the 'outer' one or the 'user's' one.

The inner item stack could actually be called 'AST stack', or 'inner AST stack' then.

[Techcable]

I think I'll refrain from such things like Parse Tree Operations now.

I agree. Your Lelek parse tree definitely looks like an improvement over the parol one. However, I think it would be nice if transformations were done at compile time and not runtime, even if it harms the user experience a bit. Preferring compile time to runtime is kind of the Rust way 😉

Based on this I hope to be able to auto-generate the inner (i.e. expanded) semantic actions including the calls of the outer (i.e. user) actions and the data types needed for the inner item stack.

I think I will give up the try to share data from the LLKParser with the inner grammar (its parse tree is not really of interest for the end user; also to store node ids outside the tree is discouraged by the maintainer of the id_tree crate). The only thing I would reference is the parsed text which is likely a great portion of memory consumption. The lifetime of it is already handled correctly in parol-runtime.

Yeah, I agree. it's very difficult to wrap the internal parse tree with a nice API for the user :(

To further complicate things, the user most likely wants either typed parse trees (like the syn API or what ungrammar does. Some might want even want to go directly to a custom AST.

I think it's probably best to stick to keeping an untyped tree as the internal representation or as some sort of "raw" API.

In fact, there seems to be somewhat of a trend towards untyped parse trees as an internal representation, then wrapping higher-level APIs on top of it:

1. it's what rust-analyser uses. They published their syntax tree library as rowan API.
2. it's what Swift's compiler uses with their internal syntax tree
3. tree-sitter does this (also a parser generator)
   • Unfortunately they are LALR(1) so it doesn't help with the implementation :(

I think automatically typing the parse tree is a good idea, but it's probably a higher priority to separate "user parse tree" from "internal parse tree" first. At least that's what I would prefer dealing with 😄

Also I struggle for better naming.

That's one of the 2 hardest problems in Computer Science, along with cache invalidation and off-by-one errors ;)

The expanded grammar is planned to be an internal implementation detail. Thus I tend to use the word 'inner' or 'internal' in relation with it.
The original input grammar would then be called the 'outer' one or the 'user's' one.

The inner item stack could actually be called 'AST stack', or 'inner AST stack' then.

In the public documentation, it makes sense to drop the "user" prefix and just call things "grammars" and "parse trees".

As an internal name, I agree "user grammar" is nice. I also think "user parse tree" or something similar is a good name for the final output :)

I also think "internal parse tree" makes sense. If we're going to commit to using a stack for the implementation, then makes sense to call it a "parse stack" (without the prefix "internal"). In that case, that is not ambiguous with "parse tree" because stack != tree.

[jsinger67]

Thanks for your reply. I really appreciate your feedback.

I'm currently experimenting with gathering information from the grammar which will be necessary to generate the type of the parse stack of the inner grammar. Also I'm collecting semantic primitives during grammar transformation and insert them as pseudo symbols into the productions ready for later use.

This is the very fist step of being able to auto-generate semantic actions for the inner grammar.

What I want to achieve is to determine for each semantic action the types of the input parameters (from parameter list for tokens and from parse stack for non-terminals) and the type of the output value (pushed on the parse stack and eventually being used as parameters of the semantic actions of user's grammar). These types are in some sense primitive elements like tokens and collections that are composable like in an algebraic type system:

///
/// Type information used for auto-generation
///
#[derive(Debug, Clone)]
pub enum ASTType {
    /// Will be generated to a Token structure
    Token(String),
    /// A type name
    TypeRef(String),
    /// A tuple, i.e. a sequence of types
    Tuple(Vec<ASTType>),
    /// Will be generated as enum with given name
    Enum(String, Vec<ASTType>),
    /// Will be generated as Vec<T>
    Repeat(Vec<ASTType>),
    /// Will be generated as Option<T>
    Option(Vec<ASTType>),
}

The type information of a complete grammar is then composed of such items:

///
/// A type system for a given grammar
///
#[derive(Debug, Default)]
pub struct GrammarTypeSystem {
    /// For each production there exists an `input` type.
    /// This type is the input related side of the semantic action associated with that
    /// productions.
    /// This type(s) correspond(s) to the parameters and is(are) feed at call time in two possible
    /// ways
    /// * First the corresponding values can be obtained from the actions's parameter list
    /// * Second the values can be popped from the AST stack
    ///
    /// The first way would actually be used for simple tokens.
    /// The second way is applicable if there are already more complex items on the AST stack which
    /// is the case for any non-terminals.
    pub in_types: HashMap<ProductionIndex, ASTType>,

    /// For each used `input` type there exists one `output` type.
    /// These `output` types are usually created as compounds of the `input` types.
    ///
    /// These types correspond to the constructed new values pushed on the AST stack.
    /// If there exists an associated semantic action of the user's `input` grammar this type is
    /// used to call it with.
    pub out_types: HashMap<ProductionIndex, ASTType>,

    /// Information to fill the semantic gap in special cases
    pub semantic: HashMap<ProductionIndex, Semantic>,
}

The source generator has to use this information then.
Semantic information is also deducible to know how to compose the output value from the input values and so on.

One type of semantic information is that a production has to start with an empty collection of a given type. The empty ListRest node in the parse tree I posted above is such a basic pattern.

Here is an example with two repetition expressions in the only production of the grammar:

S: "a" {"b-rpt"} "c" {"d-rpt"};

Next you can see the inner grammar generated from this with semantic information inserted about when to start with an empty collection:

/* 0 */ S: "a" SList "c" SList1;
/* 1 */ SList1: "d-rpt" SList1;
/* 2 */ SList1: /* Vec<SList1>::New */;
/* 3 */ SList: "b-rpt" SList;
/* 4 */ SList: /* Vec<SList>::New */;

The pseudo symbols are printed as comments here and they describe what to do here in the particular production (here prod. 2):

Vec<SList1>::New => push a new collection of type SList1 onto the parse stack

Another pseudo symbol which is still missing here is to push an item on the collection (prod. 1), maybe like this

Vec<SList1>::Push => push a new item onto the collection of type SList1 and then push it back onto the parse stack

I will hopefully end up with an auto-generated version of the inner grammar where the types and semantic logics are completely and automatically deduced from the grammar's structure.

This is all still in an early phase but I will share the progress here as soon as there is something I can show.

[jsinger67]

On branch auto-generation I added a new tool 'deduce_types'.
This can be used to check the type information parol currently collects for auto-generation.
It takes a user grammar and prints the expanded grammar followed by the type information for each production and also for each non-terminal.

Currently for a source grammar like in this example:

%start List
%%
List: [Num {"," Num}];
Num: "0|[1-9][0-9]*";

it generates the following output:

>parol deduce_types -f .\list.par
/* 0 */ List: ListOpt;
/* 1 */ List: Option<ListOpt>::None;
/* 2 */ ListOpt: Num ListOptList;
/* 3 */ ListOptList: "," Num ListOptList;
/* 4 */ ListOptList: Vec<ListOptList>::New;
/* 5 */ Num: "0|[1-9][0-9]*";

Type information:
/* 0 */ (Option<ListOpt> -> Option<ListOpt>)  { Option::Some }
/* 1 */ (Option<ListOpt> -> Option<ListOpt>)  { Option::None }
/* 2 */ ((Num, ListOptList) -> (Num, ListOptList))  { Vec::Rev(ListOptList) }
/* 3 */ ((",", Num, ListOptList) -> ListOptList)  { Vec::Push }
/* 4 */ (() -> ListOptList)  { Vec::New }
/* 5 */ ("0|[1-9][0-9]*" -> ("0|[1-9][0-9]*"))  { - }

List ->  Option<ListOpt>
ListOpt ->  (Num, ListOptList)
ListOptList ->  Vec<("," Num)>
Num ->  ("0|[1-9][0-9]*")

I chose the (A -> B) { sem } notation to convey the following information:

• A is the input type of a production, i.e. the sum of or the choice between input parameter and parse stack. The choice where to take from the data is as follows: Terminals are provided as tokens by the parser as parameters and are always taken form the parameter list. Non-terminals are taken from the stack because they are the result of semantic action previously called.
• B is the output type of a production, i.e. the type pushed onto the parse stack.
• sem is a semantic information used for special cases, where the dash (-) means standard behavior. The standard behavior is to combine input types to the output type.

I'm validating this currently. Then I will start generating the types as (nested) enum to have an automatic type for the inner parse stack.

[Techcable]

I see the auto-AST feature just landed. 🎉

Thank you for working on this. I will have to find time to play around with it :)

[jsinger67]

Yes, it was a hard work. Just to figure out how to represent grammars in terms of types.
But the results are quite surprising. A lot of tedious boilerplate code is generated automatically for the user and he can forget about the expanded grammar.
His user actions are called from the generated functions with comprehensive argument types.
I hope all works for you as well 👋

[ryo33]

Your parol is great, really great. I was going to make my LL(k) parser generator until I discovered parol, but I'm glad I did.
In my crate, I planned to generate a type-agnostic AST generator. It's a struct or trait, something like the one below.

For syntax:

%start List
%%
List: [Num {"," Num}];
Num: "0|[1-9][0-9]*";

The generated AST generator:

trait AstGenerator {
    type List;
    type Num;

    fn gen_list(num: Self::Num, list: Vec<(Token, Self::Num)>) -> Self::List;
    fn gen_num(text: Token) -> Self::Num;
}

Is it viable to have option to generate this in parol? If you agree, I will send you a pull-req in the not-too-distant future.

[jsinger67]

Hi ryo33,

first, I really appreciate your positive feedback. 😎
Like any developer, I hope that some others enjoy my work and find it useful.

As far as your proposal is concerned, I think I need some more detailed information.
I try to explain what I understood.
You merely want parol to generate a trait in this form where AST types are associated types of the trait which are named after the corresponding non-terminal.
Then you want for each production a generator function that takes the argument list corresponding to the right-hand side of the production in case, right?

Please correct me if I got something wrong! 😉

I think this should be feasible with the information parol already has collected during grammar analysis.

What I think is that you're giving up (deliberately?) the possibility to generate a functioning parser when working in this mode (this is what parol typically does).

So, in my opinion I would be glad to accept a PR from you. You should add a new argument switch that enables this special generation mode for parol. Also, I would like to keep the documentation up to date. But we can do it step by step.
If you have any questions or need help, please let me know. 👋

[ryo33]

Yes, that's what I meant. Thanks!