Access to rule name from nodes?

E.g. how do I know what type of an element was matched if the parse tree does not contain the matched rule name?

Let’s take a hypothetical programming language, which I’m trying to parse:

class Dog
  property dog_name

  def bark()
    puts "Woof!"
  end

  def sit()

  end
end

And when parsing the class definition, class can contain 0…N (propertyDefinition OR methodDefinition).

When I get the parse tree and am handling the class definition node, it’s sub-elements are (ideally):

1. property definition
2. method definition
3. method definition

Sure, I could detect the type of node by seeing if the object has key “property_name” (=> it’s a property definition) or if it has key “method_name” (=> it’s a method definition), but that’s just ugly.

I noticed there is _types field in the parser and in parse(…, options), but it seems to be unimplemented.

Any advice on this?

[atownley]

I’ve been looking at this again, and I really need it for building better error messages. My thought is something like augmenting the builders so that they set a local variable with the rule name (which you already have when you create the function (something like this):

builders/javascript.js:
212   cache_: function(name, block, context) {
213     var temp      = this.localVars_({address: this.nullNode_(), index: 'this._offset', ruleName: name }),

Then, when you were actually in each function, the rule name would be pushed onto a stack of rules in the Grammar instance so that the current rule failure would have a rule name.

Now, we probably don’t want to give a raw rule name to a user, but it’d be better than this:

SyntaxError: Line 22: expected [a-zA-Z], [0-9], "+", "-", ".", ":"

However, once you had the rule names, then your error handler could have a strings object of messages with “human” names for each of the rule name keys.

As far as I can see, this is a slight modification to the builder to get it to generate the correct code to set the variables and manage the stack and then modifications to the generated Parser instance so that it includes the top of the rule stack when it creates the SyntaxError instance thrown to the caller.

A few things that I’m not sure about are:

1. Exactly when to manage the stack in the generated function calls
2. Where in the builders to make the code
3. How to actually compile and test the code that’s in the head of the branch

I’m trying to follow the directions in the CONTRIBUTING file, but when I try and run the tests, I get a lot of errors, and, since I’m still getting the hang of the npm environment, I’m not quite sure how to get it to generate a local package that I can play with interactively.

As far as your comment to @joonas-fi about not worrying about the rule names, I think that’s fair in the normal processing sequence now that I understand how you’re supposed to construct your own object graph as the rules fire. However, I don’t think it’s accurate when you’re talking about error messages—especially when you’re trying to figure out a grammar where a) you’re still new to canopy, b) you’re a little new to PEG and c) you’re not 100% convinced exactly how to express the rules you want. 😃

I’m trying to replace a hand-written parser for two existing languages with Canopy, and, after taking a few months getting sidetracked, I’m now making good progress as we’re coming to an understanding. However, somehow, I need better error messages than the above, because the way they are, they’re only slightly better than IBM BASIC (c. 1980) “Syntax error.” messages.

Having this facility would not only make development of grammars with Canopy much faster, but it’s also important to the end product you’re building the parser for in the first place.

This is what I get when I try and build, and, for now, if I can just get it working the way I described with Javascript, I’ll be happy. I don’t need/want the other languages right now.

npm run build
npm ERR! Darwin 15.6.0
npm ERR! argv "/opt/local/bin/node" "/opt/local/bin/npm" "run" "build"
npm ERR! node v6.10.3
npm ERR! npm  v3.10.10

npm ERR! missing script: build
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /opt/devel/archistry/canopy/npm-debug.log

Happy to help implement this, but I think I need a little bit of guidance on how things work to be efficient.

Cheers

[jcoglan]

One further thing I’ll note here is that I don’t want to commit to a way of identifying rule names that user programs might come to depend on. Something I’m still considering is if/how Canopy should support composing multiple grammars together, and that it likely to affect how rules are identified since it creates a namespacing problem.

For now I’m happy to include this in error messages but less keen to put them in data that might break its format in later releases.