Saturday, March 14, 2015

Parseability in Classp

In Classp, the way that you specify that you want a parser generated for a class is by adding a %parseable indicator in the class body:
Expression {
  %parseable;
  ...
}
I've never really been satisfied with this syntax for a couple of reasons. First, the "%" sticks out like a sore thumb. It is there because without the percent I had a parsing conflict and I didn't want to re-arrange the grammar to avoid the conflict. Just the sort of problem that Classp is intended to solve!

The other thing I don't like about it is the word: "parseable". Any class with a syntax declaration is parseable in the sense that a parse can return an instance of that class. But I didn't want to use the yacc/bison word "start" because that seems too procedural. I thought of "root", but that isn't quite right. The root of a tree that you get when you parse an Expression could be any class that is a subclass of Expression.

Another possibility is to allow something that looks like a method declaration, say
Expression {
  parse();
  ...
}
"parse" is the name of the static method that is created, so this would essentially say, "there is a parse() method for this class, Classp, please create one for me."

Or we could be a bit more explicit:
Expression {
  generate parse();
  ...
}
this could one day be generalized into a feature for telling Classp to generate other class features such as additional constructors or traversal functions.

If you have an opinion, please respond in the poll at the right.

Well the poll closed with a unanimous vote  for "generate parse()". I'll see about changing the syntax to that when I have time to get back into the code.

No comments:

Post a Comment