Should ceylon.ast comply with the compiler instead of the specification?

[lucaswerkmeister]

The ceylon.ast.core module documentation says:

ceylon.ast seeks to comply only with the Ceylon Language Specification, not its implementation in the compiler.

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:

• It would probably make ceylon.ast more useful.
• @jvasileff might finally stop pestering me with non-bugs like #122.

Cons:

• The additional rules in the compiler are undocumented and subject to change with even less notice than the specification. I recall several cases where I only noticed a spec change relevant to ceylon.ast or ceylon.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 by ceylon.ast.
• If a feature is later adopted in the specification, the specification’s description of it might be different from the ceylon.ast model, and ceylon.ast would have to be updated, breaking users’ code.
• We boast an “exhaustive… specification” in our quick intro, so this issue should not even be up for debate in my opinion.
• @jvasileff might pester me with a lot more now-actually-bugs like #122.

[jvasileff]

My thoughts:

• For ceylon.ast to be used for a backend, it's important that it accept everything that passes through the typechecker without error. This includes code written for all backends, due to how native works.
• For other proposed uses, such as https://github.com/ceylon/ceylon/issues/1865, it seems the same
• There don't seem to be that many deviations from the spec. I've reported all that I have found.

[lucaswerkmeister]

There don’t seem to be that many deviations

I assume that you don’t want to accept try () and suchlike? Because there’s a lot more cases like that.

[jvasileff]

accept everything that passes through the typechecker without error

To be clear, I mean within reason, and for things that aren't considered bugs-that-will-be-fixed in the typechecker.

[jvasileff]

try ()?

[lucaswerkmeister]

Yes, because that gets you an

error: empty resource list

instead of an

error: incorrect syntax: extraneous token ',' expecting closing parenthesis ')'

which is what the “how far do we go?” question in the issue is about.

[jvasileff]

I see. I'm not currently exposing ceylon.ast to trees that have errors, recognition or otherwise.

Except... I am concerned about what to do about native(other) declarations that have errors like that, since I'm currently ignoring errors that don't apply to Dart. Its unclear to me if the ones I should care about can be distinguished from those that can't. This is a tricky problem:

native("jvm") void foo() {
    try() {}
}

crashes compile-dart, while the same w/o native does not.

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 ceylon.ast.redhat.

[jvasileff]

@lucaswerkmeister I propose we resolve this issue by saying that "within reason" ceylon.ast should accept whatever the typechecker accepts without error, for any backend, after full typechecking.

Hopefully some form of pre-processing or filtering can address issues with allowing errors in native("other") declarations, but that seems like a separate issue.

Tell me if I'm wrong, but it seems that having ceylon.ast vastly reduce its type safety and assertions, to support uses such as being used during typechecking or ceylon/ceylon#1865 before typechecking, would be a much bigger, more complicated, and more fundamental change.

[lucaswerkmeister]

@jvasileff opinions on fe3a0e2?

[jvasileff]

@lucaswerkmeister I think that looks great 👍

[lucaswerkmeister]

Alright, then let’s close this issue :)