-
Notifications
You must be signed in to change notification settings - Fork 3
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
Should ceylon.ast comply with the compiler instead of the specification? #123
Comments
My thoughts:
|
I assume that you don’t want to accept |
To be clear, I mean within reason, and for things that aren't considered bugs-that-will-be-fixed in the typechecker. |
|
Yes, because that gets you an
instead of an
which is what the “how far do we go?” question in the issue is about. |
I see. I'm not currently exposing Except... I am concerned about what to do about native("jvm") void foo() {
try() {}
} crashes Maybe I can pre-process the rhAst to remove stuff I want to completely ignore. But then, what if there's some reason I do need those declarations? Just brainstorming, another option may be to have some filtering mechanism in |
@lucaswerkmeister I propose we resolve this issue by saying that "within reason" Hopefully some form of pre-processing or filtering can address issues with allowing errors in Tell me if I'm wrong, but it seems that having |
This was discussed in #123, and this change makes ceylon.ast a lot more useful both for writing compiler backends and for supporting AST transformers.
@jvasileff opinions on fe3a0e2? |
@lucaswerkmeister I think that looks great 👍 |
Alright, then let’s close this issue :) |
The
ceylon.ast.core
module documentation says:Should we abandon this, and instead seek compliance with the compiler?
If yes: how far do we go? The module documentation cites the example of empty resource lists for
try
, which are permitted by the grammar so that the compiler can give you a better error message than a syntax error. Should cases like this be allowed as well, or only cases that are actually legal on at least one backend, without any error messages, like #122?Pros:
ceylon.ast
more useful.Cons:
ceylon.ast
orceylon.formatter
by sheer luck, and it’s likely that I already missed some that @gavinking smuggled past me. I can’t imagine how I could hope to keep up with the compiler if every change potentially needs to be reflected byceylon.ast
.ceylon.ast
model, andceylon.ast
would have to be updated, breaking users’ code.The text was updated successfully, but these errors were encountered: