Access name of production rule in postprocessing function?

I’m using Nearley to generate my own abstract syntax trees. I’d love to be able to use the same postprocessing function across production rules, without having to repeat the name of the production rule twice in my code. For example, instead of this:

foo1 -> "bar1" {% function(data){
    return { data: data, type: 'foo' }
} %}

foo2 -> "bar2" {% function(data){
    return { data: data, type: 'foo2' }
} %}

# etc.

I’d love for the library to be able to do this:

@{%
    function makeNode(data, reference, fail, name){
    	return { data: data, type: name }
    }
%}

foo1 -> "bar1" {% makeNode %}
foo2 -> "bar2" {% makeNode %}

Or better yet, set this to the Rule object:

@{%
    function makeNode(data){
    	return { data: data, type: this.name }
    }
%}

Can this be made possible?

[deltaidea]

Ah, got it! Thank you.

So a more straightforward solution is:

@{%
    const makeNode = name => data => ({ data: data, type: name });
%}

foo -> bar {% makeNode("foo") %}

While this requires you to duplicate the rule name, it separates CST from grammar details: you’re free to rename rule foo or use makeNode in a macro where the name isn’t preserved in runtime.

[kach]

There really shouldn’t be a way to do this. As it stands, we make no guarantees on the internal structure of the Rule object. Its fields might change if we decide to implement some kind of optimization or something. Your day-to-day nearley grammars should not depend on postprocessing based on the Rule object. And @darrylyeo’s example is simple enough that I don’t think anyone minds the redundancy of writing something like the following.

foo1 -> xxx {% makePP.bind({name: "foo1"}) %}
foo2 -> yyy (% makePP.bind({name: "foo2"}) %}

If we introduce this as an officially-supported “feature”, the potential for doing icky things is just way too high. And, historically, we’ve seen that people not only use nearley features, but in fact often use them in surprisingly scary ways. Nobody wants to deal with the weird edge-cases, backwards-compatibility issues, and painful bug reports that would result if this becomes mainstream.

---

Now, if this is the case, then why do I want it documented? Well, if you actually do know what you’re doing and need a patch for some reason, then binding this to Rule is a nice side-effect of the way nearley works internally, providing you with a hook for getting started with your wizardry. The Rule object (currently!) is quite simple to understand, and provides enough reflection for advanced developers to do some neat things.

For example, you might want to dynamically generate a parser based on various conditions (imagine an interactive fiction game where your vocabulary increases as you pick up objects or whatever). You can do that with nearley.

But — crucially — this is one of those with-great-power-comes-great-responsibility moments. If we are giving people the power to do cool/awful things, then we should make sure they know that they are wandering off the trail and should keep an eye out for bears. That is why I think it should be labeled with some kind of warning.