less / less-meta

Like meta.stackexchange, but for Less. For documentation, please go to less/less-docs
MIT License
5 stars 1 forks source link

Proposal for reducing backtracking for mixins / functions #35

Closed matthew-dean closed 3 years ago

matthew-dean commented 4 years ago

@less/maintainers @less/admin

I'm currently working on re-writing the parser for Less. I'm trying to simplify the amount of backtracking in the parser, of which there currently is quite a lot, and some of that is built into the grammar.

When I came to looking at semi-colon-, comma-separation- in mixins and functions, parsing gets pretty complex very quickly.

I came up with a proposal that I think would remove the need for backtracking in mixins / functions, which I posted today.

Proposal: Instead of looking ahead for commas / semi-colons, comma-separated values can be wrapped in a (currently-proposed) value() function.

Ex:

.my-mixin(@val: value(a, b, c), @other: foo);

In a future major release, the parser would accept either semi-colon or comma separators, but they would not change the interpretation of values as they do now.

.mixin(@a, @b, @c) {
  // ...
}

.mixin(a, b, c);
.mixin(a; b; c);
.mixin(a; b, c); // error - mixed comma and semi-colon separators
.mixin(a; value(b, c); d); // makes it very clear / readable what the 3 arguments are

This would allow the parser (at least in the case of functions, since mixin calls / definitions still have ambiguity) to more simply parse arguments, and also doesn't change the reading of an argument based on what comes after.

Thoughts welcome.

matthew-dean commented 4 years ago

Alternatively, this could echo the ~"" syntax, and could be ~() to escape parens.

Meaning:

.mixin(a; ~(b, c); d);

Hmm, that seems a lot cleaner.

matthew-dean commented 3 years ago

I added ~(b, c) syntax to 4.0, but I have not deprecated semi-colon separators. They should stay for a while as it was recommended syntax.