fix: Enforce a line break between annotations

[max-sixty]

Found this while doing the formatting, we don't yet enforce this

Possibly there are other areas we don't enforce this sort of thing?

[max-sixty]

Actually unclear whether this was an error — maybe we don't need a line break there? We have an existing test for the annotation being on the same line: https://github.com/PRQL/prql/pull/4699/files#diff-60240bd4141669c59055b007289ef4f32d6004a28ef55429c5fd1f0c972d7f54L2851

        @{binding_strength=1} let add = a b -> a + b

[aljazerzen]

Actually, yes, we could support this. I think other languages like Java and Python do support it.

[kgutwin]

Python doesn't support inline decorators, this is a syntax error:

class Foo:
    @property def bar(self) -> str:
        return "xyz"

I'd advocate for exactly one newline between an annotation and the statement. Supporting more than one newline between annotations and statements is probably not a good idea. The following is currently syntactically valid but seems very problematic:

@{binding_strength = 1}


# you could fit 
# a whole lot of distracting
# comments and whitespace in here



from foo

[max-sixty]

Supporting more than one newline between annotations and statements is probably not a good idea.

Yes, I had a similar question in my mind.

I think one issue with disallowing this is that (almost?) no languages discriminate between one and multiple new lines. They do format things to be contiguous, but don't enforce it semantically. For example this is valid in python, even though it'll lose the new line after being formatted:

@decorator

def foo():

...so it could be quite confusing to behave differently from those languages.

And we'd have to consider whether to have this in other areas of PRQL — would it be OK to have additional new lines in tuples etc...

We could still format (or even lint) to the correct form.

[kgutwin]

Interesting! I had never noticed that about Python before.

I agree that it could be weird to enforce this for this case only. I would say that it's probably less important to be strictly aligned with other languages, but is more important to not have to fight with the parser grammar to make this happen for specific cases, and to have the PRQL language itself be consistent. There are definite cases, like you said, where having things like multiple new lines in the middle of a tuple definition would be very sensible.

And yes, formatting/linting to the canonical form is important. Do you think that interposed comments like I showed in my example are going to be tricky to handle with the new comment-aware parser?

[max-sixty]

And yes, formatting/linting to the canonical form is important. Do you think that interposed comments like I showed in my example are going to be tricky to handle with the new comment-aware parser?

I think it should be totally fine. Most of the parser work itself I merged over the weekend, and the formatting will likely be done without further changes to the parser. But we will see :)

[max-sixty]

Added a couple of notes & tests re similar issues