Optimize list parsing

[TPGamesNL]

Description

Changes the order of list parsing. For example: 1, 2 and 3. Skript starts by separating the whole expression into n pieces (already taking things like parentheses into account), here "1", "2" and "3". Then, it starts parsing the pieces.

Before this change, it takes the first n-1 pieces, and tries parsing them together as a single expression. If that failed, go for the first n-2 and so on, until one worked, at which point it'd advance to the remaining pieces and do the same on those.
With this change, it instead first looks at the first piece, then at the first two, then the first three etc.

This PR also adds another optimization for list parsing, which is that the parser would originally first try parsing the text as a list, and only then check if the pattern actually allows a list here. I've moved this check before the list parsing to the extent that was possible, so it won't parse when it's not needed.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #4025, #5122, #5243

[TPGamesNL]

Added another fix to this PR, concerning #5122, details in first message

[bluelhf]

Is respecting the maximal munch principle a goal? If so, does this change do so?

[TPGamesNL]

Before, it did respect the maximal munch principle, but with this change it does no longer.

This also has a functional difference, for example set {_l::*} to "abc", length of "def", "ghi":

Before change:

• Interpretation: "abc", length of ("def", "ghi")
• Result: "abc", 3, 3

After change:

• Interpretation: "abc", (length of "def"), "ghi"
• Result: "abc", 3, "ghi"

For this reason, I've tagged this PR as up for debate:
I would like input on which of the two interpretations above should be preferred, and if the parsing speed optimization is worth the breaking change.

[APickledWalrus]

I am in support of this PR's changes. I would also say that the new interpretation is better than the old one.

[AyhamAl-Ali]

+1 ✅

IMO the new interpretation is better and that what I would expect (and maybe many others).

For those who prefer the old interpretation they should always help the parser to identify their intentions about lists by using braces around them.

[TheBentoBox]

Strongly in support of this change. @TPGamesNL's example in the reply above is a strongest argument for it to be made

The "Before change" version is (to me) clearly unintuitive and is undefined behavior from the perspective of a user -- it's unclear where Skript would interpret the separation between list elements. With "After change", it's an easy and strict rule -- the commas are the list element separators, and if you need grouping within the context of one list element you should use parentheses.

Principles like maximal munch are nice for when you're conflicted between two valid and equally viable seeming paths (in those scenarios, why not follow a commonly recognized principle?), but I'd never use them as an argument to lean towards an implementation which lacks clarity.

[bluelhf]

I can't think of any examples where this interpretation of lists would be worse. LGTM :)

If I recall correctly, @Moderocky has prior experience designing and implementing programming languages, maybe she'd like to weigh in as well?

[Moderocky]

I am in favour of the change because I think it's more (immediately) intuitive than the original.
I think it might be worth testing this over a large number of list examples so that we can identify all the possible differences and then make it clear to users what they would need to change to get their old behaviour.

[Moderocky]

Looks fine to me.

[TheLimeGlass]

@TPGamesNL Conflicts

[TPGamesNL]

@TheLimeGlass resolved 👍