Seems like the problem is all the way in pretty_assertions
It might that somewhere a \r is being inserted
I know that @Joshua Warner or @Brendan Hansknecht will come in and tell me I'm doing something terribly silly and obviously wrong - but I can't see it. And I'd like to keep these tests
I'll try similar in snapshots and see if we get the same issue
Looking into snapshots, I'm noticing that this is valid:
N<l(r*N)
And that may cause some issues for keeping WSA and PNC together.
The only solution I see is if an ident_seq is followed by a parenthensized expression or tuple and there is no SpacesBefore, we convert. But even that changes the semantics of code like this.
Anyone have a clue for how to disambiguate the two?
Right now this is parsed as:
N < l (r * N)
With any reasonable interpretation of PNC, there it would be parsed as:
N < l(r * N)
as in (with WSA):
N < (l (r * N))
Basically, we would have to have a backwards incompatible change where application would require a space between an ident subsequent expressiosn
I don't think there's a way around that
Which actually is surprising that we allowed WSA without the err, whitespace
It's almost always better to parse maximally and give errors rather than fail parsing IMO
And instead, i guess, treated the end of an ident and the beginning of a non-ident expr as "whitespace"
Unless there are perf implications
I think you should parse the grammar and bail as sson as you get something you don't expect
You can continue parsing and add an error report
But I personally prefer strictness in things like whitespace
I think I'd prefer Richard to weight in here, this is probably an impactful change
Anthony Bullard said:
I think you should parse the grammar and bail as sson as you get something you don't expect
When you say bail, do you mean "fail parsing the rest of the module" or "fail this top-level node, i.e. the function body"
The latter can be a good user experience, but the former always sucks
Fail just the def
Okay, great
Yeah, that's seemingly what Joshua Warner has been trying to do
We want to be robust for the LSP and other tools
And he's got a lot more of a knowledge base here than I do
I always built the former because they were early/hobby parsers, but the latter is the way
24 messages were moved here from #contributing > Parens and commas work by Anthony Bullard.
For context, this was to make this a top-level thing to debate
It doesn't seem like there is much of any concerns with this change, so I'll take silence as a Go Ahead
I don’t think it’s a problem to change semantics of tests (particularly snapshot tests)… so long as those tests aren’t properly formatted. I.e. changes are fine so long as they won’t affect code that has previously come out of the formatter.
:+1:
Last updated: Jul 06 2025 at 12:14 UTC