Consistent guard expressions.

[seven-phases-max]

This is just a follow up of discussions at #2776 (comment) and #2798 (comment).
A.k.a.:

"Less needs to finally stop pretending that guards are similar to CSS @media, they are not".

In summary, currently (at 2.6.0) we have these two directly opposite requirements:

when (true) and (true) // valid
when (true) = (true) // not valid

and in the same time

when (true = true) // valid
when (true and true) // not valid

It's not that this is impossible to code, but it does not look practical, taking into account that all this expressions may nest each other and must follow certain operator precedence.

[matthew-dean]

I'm not sure I see the issue?

[matthew-dean]

when (true) and (true)    // valid - expressions are "true" and "true" -  "and" is a joining condition
when (true) = (true)      // not valid - you can't test the equality of expressions
when (true = true)     // valid  - "true = true" is an expression
when (true and true)   // not valid - you can't join two expressions without putting the expressions in parentheses

[seven-phases-max]

"and" is a joining condition

No, you're just staring to invent artificial definitions. All of this are just left op right binary expressions:
a + b
a * b
a = b
a > b
a or b
and so on.
Some of them are logical (thus returning true/false) others are more generic (returning number/color or whatever) but still these are just binary expressions of the same category. Thus having different parenthesis requirements for some of them is the language defect.

---

when (true) = (true) // not valid - you can't test the equality of expressions

Why exactly ((@a > @b) = (@x and @y)) is valid in all conventional languages (assuming = is ==) but in Less it's not? ;)

[rjgotten]

@seven-phases-max

Your problem is that you're seeing this as a simple nesting of binary expressions. It's not.

Mixin guard expressions follow the guard syntax of CSS media directives first and foremost. These specifically require parentheses around conditions and join conditions together using an and operator. The contents of the conditions are, for mixins atleast, specified as binary expressions that evaluate to a type-weak boolean, i.e. , a truthy/falsy value.

when (@a > @b) = (@x and @y) is not a valid mixin guard expression because the = binary comparison operator is being used at the level of the CSS media guard syntax and not of the normal boolean expression syntax.

Conversely, when ((@a > @b) = (@x and @y)) is valid because it transfers from a CSS media guard to a normal boolean expression when the outer set of parentheses is opened.

[seven-phases-max]

@rjgotten

Mixin guard expressions follow the guard syntax of CSS media directives first and foremost.

We've been there already.
And that's why this feature request is here in first place, if we want a consistency in guards we must forget about any @media stuff - because it's:

odd and lame

_{Strictly speaking it's not even Less who wants to not follow @media-like conditions, but also CSS itself:
(orientation: portret) -> orientation == portret
(min-width: 100px) -> width > 100px
and so on, but
[attr="foo"] // uh?
Those @media-conditions turn out to be nothing but a set of syntactic and semantic kludges sitting on top of each other invented only to keep a browser CSS parser as simple as possible. It does make perfect sense given the very limited applications of the @media and @support, but can't make any sense for guards (unless the goal is to produce the most confusing expression apparatus ever ;), especially yet again counting that Less guards already have very few to do with @media (starting right at the basic not (false), (true) expression).}

[matthew-dean]

No, you're just staring to invent artificial definitions

That's what I'm best at! ;-)

Let's skip to the important part at the end. TL;DR You're essentially right, that parentheses should just provide "grouping" and evaluation order, and shouldn't change the types of operations allowed.

Detailed explanation:

---

I wasn't being arbitrary about the expressions. There are three types of operators being talked about here: arithmetic; equality and relational; and conditional. That's what I mean by "joining condition", that in your examples you had different types of operators that have different rules, so you can't directly compare them.

Do many programming languages allow you to use all operators in similar ways? Yes. Do all? No. One of the tricky things for Less, of course, is that arithmetic operators are an invention of Less on top of CSS, whereas conditional operators are not.

That doesn't mean we shouldn't treat them all that way. I was responding to the comment (I guess implied comment) that current Less operator rules are self-contradictory, which they aren't. So my only goal was explanation, not an endorsement of the behavior.

So, to be clear, I'm not against this: Well.... I kinda am. This gets too complicated on the parsing side. Arithmetic and comparison needs to stay in parentheses.

when (less) = (less)  // same as:
when (less = less)

Less should essentially collapse all arithmetic operations, then equality/relational, then conditional, then the "not" keyword (to negate the entire evaluation), and that order could happen several times depending on the nesting of parentheses.

[matthew-dean]

For some reason I didn't see the previous 2 comments when I posted mine.

The thing is, @rjgotten and @seven-phases-max, you're both right, and I'm not just saying that to be diplomatic. That is:

1. Guards follow(ed) the syntax of media queries. And as such, and and or (alternatively comma) have a historically different syntactical role than arithmetic / equality.
2. Media query syntax is actually pretty shitty. (min-width to test the width property? Really?)

From the hand-off of Less to a larger team mid 1.x and throughout Less 2.0, I think we were extremely cautious about syntax / changes. And that was actually very smart to maintain consistency. Moving forward into 3.x+, I've been suggesting we kill our darlings; that is, don't treat historical behavior / syntax of either CSS or Less as the best way to do it.

We can still maintain the goals of simplicity, intuitiveness, and a concise feature set of the language without preserving all the things that we may have a different perspective on now.

So, at this point, I would agree with @seven-phases-max just because it's reasonable that a developer / designer new to Less would be confused by current behavior. Being more "faithful" to CSS over intuitiveness is not the best trade-off.

[rjgotten]

@seven-phases-max

Those @media-conditions turn out to be nothing but a set of syntactic and semantic kludges sitting on top of each other invented only to keep a browser CSS parser as simple as possible. It does make perfect sense given the very limited applications of the @media and @support, but can't make any sense for guards (unless the goal is to produce the most confusing expression apparatus ever ;), especially yet again counting that Less guards already have very few to do with @media (starting right at the basic not (false), (true) expression).

@matthew-dean

Media query syntax is actually pretty shitty.

Don't get me wrong. I whole-heartedly agree with those statements. I was simply not aware you were ok with breaking back-compat in such a way, so I was trying to explain why current versions of Less have guards the way they do. :)

So, at this point, I would agree with @seven-phases-max just because it's reasonable that a developer / designer new to Less would be confused by current behavior. Being more "faithful" to CSS over intuitiveness is not the best trade-off.

I would as well. The mix-and-match between CSS-ish media guards and more classic boolean binary expressions is a bad thing that negatively impacts readability.

[matthew-dean]

I was simply not aware you were ok with breaking back-compat in such a way, so I was trying to explain why current versions of Less have guards the way they do

Right, looks like I was doing the same thing. As far as breaking changes, we've already proposed some breaking changes for 3.0 in other threads. So, while I'm not suggesting we break everything, regardless, I would like 3.0 to be an evolutionary step forward for Less.

[seven-phases-max]

To be honest I did not even consider this as important (why bother if it works as-is?), until I actually dug into #2798 and found that most likely the only way to fix it is to throw yet another hundred of ifs in :)
And all that code just for relatively minor improvement (and the overall thing still remains quite limited and becomes even more little-bit awkward) w/o even being sure that it won't fail in some not-predictable edge-case, because most of those ifs are about detecting different parens for outer/inner and media-like/non-media-like expressions w/o any straight-forward grammar rules.
Hence the ticket (i.e. current behaviour starts to harm).

_{My mistake I guess was just too minimalistic initial post (assuming a reader has prev. discussions at the mentioned issues in mind).}

[seven-phases-max]

Technically the only thing to decide (beside just "yes/no" for the ticket as such) is if we want to require outer parens or not.
I.e. should it be:

when (whatever)

or

when whatever

The first is more traditional but totally breaking (you'll have to rewrite all of your when (@a), (@b) and (@c) stuff). The second is partially backward-compatible (not counting any operator precedence), but someone might not really like when not @a-ilke things.
(Additionally the first assumes the comma logical operator is simply removed, while the second needs a decision on keeping it or not - counting this side-effect)