AST annotations

[Praetonus]

Rendered.

[jemc]

Can you further specify the new syntax allowed within the \ brackets?

For example, can the annotation list span multiple lines? What is the form of each annotation? What characters are allowed? Can they start with a digit?

[jemc]

If we use the \ character, will we regret it if/when we want to allow use of \ for line continuation (I'm thinking C-style adjacent-line string literals at the moment).

[Praetonus]

Can you further specify the new syntax allowed within the \ brackets?

Yes, I'll detail what identifiers can be (it's meant to be the same as Pony identifiers).

If we use the \ character, will we regret it if/when we want to allow use of \ for line continuation (I'm thinking C-style adjacent-line string literals at the moment).

I'm not sure. Maybe we'd be able to do some parsing tricks. I'd be happy to use something else but there are not many available symbols left and existing symbols would be ambiguous, unless there is something that can only occur in the middle of a grammar rule, but I don't think there is.

[Praetonus]

Going into final comment period.

[SeanTAllen]

All the examples are single word.

What's the reason for allowing more than a single word in annotations?

Thought: aren't docstrings a sort of annotation?

[Praetonus]

What's the reason for allowing more than a single word in annotations?

The main reason is flexibility. As we add annotations, it will probably make sense to allow different and unrelated annotations on the same language construct, to avoid mutual exclusion of unrelated things.

Thought: aren't docstrings a sort of annotation?

I'd say docstrings are annotations for the programmer (as documentation), and the annotations of this RFC are annotations for tools (either the compiler or third-party tools). Since the latter can affect the final generated code, I don't think it would be good to use the same syntax for both.

[Praetonus]

We discussed this on the sync meeting. There are some caveats with the proposal and the LL(1) grammar of the language. This wouldn't be problematic for the parser implementation in the compiler but it could make parsing for third-party tools more complex. We decided to accept a modified version of the proposal, by allowing annotations only after keywords. This is sufficient for the compiler annotations we want to add and it can be revised if somebody comes up with something that isn't possible with that scheme.

I'll amend the RFC and merge it.

[Praetonus]

Amended.

@sylvanc @jemc @SeanTAllen If it looks good to you, I'll go ahead and merge.

[sylvanc]

Looks good!