New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overloading parameterized rules? #57
Comments
Hi Blake, The ability to overload parameterized rules is something I've wanted for a while, too. Wouldn't it be nice if there could be a one-parameter variant of
I've already got a plan for how this will manifest in the semantics, and how it will be implemented. I'll do my best to commit it in the next week or two. Thanks for filing! Cheers, |
Hello Alex! I think the assumption of a comma as the default ListOf separator makes sense. It would certainly reduce a little bit of clutter in the syntax definition I'm currently working on. I started taking a look at the code to see how it might be implemented, but I think I'll leave it to you as you've already been thinking about it and know this code base much better than myself :) Looking forward to it! |
Sounds good! I'll try to post some details here in the next couple of days, that way you can tell me if there's a better way :) |
My guess is that the simplest implementation is just concatenating the
|
Right, that's where I was headed, too. My idea was to use Prolog-style names for the rules, e.g.,
Every rule will have this Back to preparing for tomorrow's lecture!! |
I'm a bit concerned that this will add additional complexity to the API, without providing a whole lot of benefit. The I'm also not sure how the "so long as it's not ambiguous" would work. Say today that someone has a grammar that uses ListOf/2, and they name the semantic action Since you can always deal with the lack of |
Hi Pat, you make good points, and we should think about this carefully. First, it's useful to separate what we want -- the ability to provide default values for rule parameters -- from the mechanisms that might support it, e.g., overloading for rules.
This wouldn't be allowed, because it's ambiguous! This is because every grammar inherits from the
In grammars, you would never have to write the Anyway, I agree that we have to think about this a little more. To be continued. |
But what if we didn't add a new Forget about ListOf -- say I have the following grammar:
I write an attribute for this grammar, and since there is only one rule named Then, someone else extends my grammar:
Now, they want to extend the attribute that I wrote before. Since Now, not to say that this is a major problem, but I think it could be confusing. |
Since ECMAScript is one of the current major examples for an Ohm grammar and it is a grammar where ES2015 could make use of a lot of rules from ES5 (as currently hinted at in es6.ohm) here is another good use case where some kind of overloading could make sense:
for example could not be reused as something like this would be necessary:
Note: That the grammar used in the spec has an interesting approach to that issue and expands
to
|
Hi Pat,
Right, it could be a little confusing for now but I'm not super worried about it. (See the last part of my comment.) In any semantics for Suppose someone comes along later and writes a grammar Coming back to the confusion thing: these names are only part of the verbose and clunky "assembly language" interface for Ohm grammars that we're exposing and using right now. My hope is that soon enough we'll have an editor for semantic actions, and this clunky interface will become an implementation detail that programmers don't ever have to see. Not only will this avoid confusion, but it will also eliminate some of the portability problems you mentioned earlier. Cheers, |
Sorry to go slightly off-topic, but...
Is there more information about the editor anywhere? |
Hehe, unfortunately not yet. But "soon enough" :) |
Would there be any objection to allowing parameterized rules to be 'overloaded' in Ohm?
I am talking about multiple rules with the same base name, but a differing number of parameters. I'm not sure if there is any 'type' associated with a parameter that could be further disambiguated on, but I imagine that would also be useful, if possible.
Example:
The text was updated successfully, but these errors were encountered: