-
Notifications
You must be signed in to change notification settings - Fork 164
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
Coercions parentheses #156
Comments
This seems like a good idea. I wonder if we could go one step further in generalization and instead have a variant of
which would then become only
and let the user define the parenthesized production (or not...). What do you think? |
I think your solution is better than mine.
I guess one might also do weird combinations between priority levels -- if anyone will find any use for such a thing. |
Just developing on the edit on the above comment, and thinking aloud.
I got the following output, from inputting the string
Same output in Haskell. |
Hum, that's a good observation. In the first case, where you have two different kind of brackets used for grouping expressions, it's going to be impossible to distinguish the two during pretty printing. But it won't be possible to distinguish them in the AST either, so they have to be semantically equivalent. In the last example, we should definitively try to do the right thing! |
Oh, I was just now looking at the thread too :) I think I can try to do something on this in the next month. |
The current syntax of coercions is
coercions <category> <levels>
e.g.
coercions Exp 2
This is translated as a cascade of
<level>
+1 dummy-labeled productions, like e.g.The introduction of the parentheses symbol might not be what the user wants.
I propose to have an additional construct
coercions <category> <levels> <leftp> <rightp>
so that
coercions Exp 2 "[" "]"
becomes
The text was updated successfully, but these errors were encountered: