Preamble on single line causes a syntax error

[cmnrd]

The following program

target C

preamble {= #include <math.h> =}

main reactor {
  reaction(startup) {= lf_print("Maximum of 42.0 and 75 is %.2f", fmax(4.20, 75)); =}
}

produces this error:

6 | main reactor {
7 |   reaction(startup) {= lf_print("Maximum of 42.0 and 75 is %.2f", fmax(4.20, 75)); =}
  |                     ^^ mismatched input '{=' expecting '=}'
  |
8 | }

I am not sure what is going on here, but it looks like there is a problem in the grammar.

[lhstrh]

The problem is that # (...) is recognized as single-line comment, which captures everything on that line including the trailing =}. (Also see https://github.com/lf-lang/epoch/issues/6.)

One way to get past this is to stop allowing Python-style comments in Lingua Franca code by changing

terminal SL_COMMENT: ('//' | '#') !('\n'|'\r')* ('\r'? '\n')?;

to

terminal SL_COMMENT: ('//') !('\n'|'\r')* ('\r'? '\n')?;

Alternatively, we could exclude common macros like include or ifdef in this regex, but that would be a very brittle solution. I think we're better off disallowing Python-style comments in LF code as I haven't seen them used very much, anyway. This would be a breaking change though.

[cmnrd]

Can we not give the code block rule precedence over the comment rule? I think we shouldn't parse comments within code blocks.

This seems to be another indicator, showing that mixing languages isn't the best idea.

[lhstrh]

I agree that we shouldn't, but we are doing this because it is the only way we know to not make the embedded target code look like a single token in Epoch. So there are two more options besides removing support for Python style comments:

• end support for Epoch; or
• implement custom tokenization/highlighting for Epoch that doesn't require applying the same parse rules inside reaction code as outside of it.

I personally don't know how to implement the second option and think it might be very difficult to achieve. @as-r might be able to comment on this...

[cmnrd]

If we process the code block as a single token, would this affect the VS Code extension? If not, then maybe we should just accept this limitation of Epoch.

[lhstrh]

I don't think so. We do custom highlighting for reaction bodies in VS Code already.

But why do we need to have so many styles of writing comments in LF? If we want to focus less on mixing, then wouldn't it make more sense to just pick one style?

[cmnrd]

But why do we need to have so many styles of writing comments in LF? If we want to focus less on mixing, then wouldn't it make more sense to just pick one style?

To me this is an orthogonal question. Even with the proposed fix, https://github.com/lf-lang/epoch/issues/6 would remain an issue. If the // is used in a code block on a single line, we would have the exact same problem as described in this issue.

The question of this issue is: is the behavior in the initial comment and in https://github.com/lf-lang/epoch/issues/6 a bug or a feature? If we consider it a feature, we should try to improve the error message and provide hints on how to resolve it. If we consider it a bug, then we should fix it, and apparently the only real fix is to stop parsing target code bodies.

To me this looks more like a bug and I wouldn't mind if we lose the superficial code highlighting in Epoch.

Back to this question:

But why do we need to have so many styles of writing comments in LF?

Because in an LF file with the Python target it would be strange to mix Python-style comments in code blocks with C-style comments in the LF code. We will have this problem as long as we mix LF and target code in the same file. If we want to simplify things, the right path seems to be separating coordination (LF) code and target code.

[lhstrh]

To me this looks more like a bug and I wouldn't mind if we lose the superficial code highlighting in Epoch.

This is where we disagree; it's not a matter of superficial code highlighting. Without this tokenization hack, Epoch is essentially useless as an editor because the entire body is shown as a single token (you cannot even select single words). So if we get rid of this, to me, this means the end of Epoch -- unless we find a proper fix for this problem.

[petervdonovan]

is the behavior in the initial comment and in https://github.com/lf-lang/epoch/issues/6 a bug or a feature?

It is hard to deny that https://github.com/lf-lang/epoch/issues/6 is a bug, but I am inclined to tolerate this and https://github.com/lf-lang/epoch/issues/6 while we wait for a "proper fix." I think that it will be unwise to spend too much time fiddling with these details before we have the software infrastructure that would be required in order to solve the problem in a non-hacky way.

[lhstrh]

is the behavior in the initial comment and in lf-lang/epoch#6 a bug or a feature?

It is hard to deny that lf-lang/epoch#6 is a bug, but I am inclined to tolerate this and lf-lang/epoch#6 while we wait for a "proper fix." I think that it will be unwise to spend too much time fiddling with these details before we have the software infrastructure that would be required in order to solve the problem in a non-hacky way.

This has been my stance too... But what to do about this bug in the meantime?

[lhstrh]

I should note that @petervdonovan already took care to avoid hitting this corner case in the formatter, so at least we're sure that the formatter doesn't output something like this that won't compile...