Allow parametrized mixins as detached rulesets to form 'lambdas'

[rjgotten]

It seems that currently LESS only supports 'pure' rulesets to be passed along as mixin arguments or stored in variables as detached rulesets.

I suggest to extend this support to incorporate parametrized mixins, essentially giving LESS the capability to work with lambdas.

E.g.
One would be able to write

.list {
  .forEach(foo bar baz, (@item, @index) {
    @i : (@index + 1);
    > li:nth-child(@{i}):before {
      content : "@{item}";
    }
  });
}

where .forEach is defined as

.forEach(@list, @lambda) {
  @n : length(@list);

  .for(0)
  .for(@index) {}
  .for(@index) when (@index < @n) {
    @lambda(extract(@list, @index), @index);
    .for(@index + 1);
  }
}

Lambda mixin support would also neatly resolve recurring issues with function return arguments and the ugly hack where variables 'bubble up' to parent scope if said variables are as of yet undefined in said parent scope.

The suggested practice could become to adopt continuation style programming; passing 'return values' along into a lambda mixin to continue down the scope chain. This kind of mechanism is more transparent to users, less brittle by avoiding issues with potential variable name collisions and just fits in better with the overall functional programming paradigms that the LESS syntax is built on.

[EDIT]
Having just had a look at the way detached rulesets and calls are implemented in the AST, I think very little needs to happen to make this work. Even on the parser side of things, it seems fairly simple to just parse an optional block of mixin.args before blockRuleset in the detachedRuleset parser function and pass the arguments along to the tree.DetachedRuleset node instance. (The tree.DetachedRuleset would need to be extended with the params evaluation from tree.mixin.Definition, ofcourse.)

[seven-phases-max]

the ugly hack where variables 'bubble up' to parent scope

Just in case this is not ugly hack but well defined language facility.
(I also can't get the idea of solving "up-chain scope issues" with "down-chain parameter pass feature", these do not seem to be related, do they? But well, never mind, the feature remains useful regardless of this anyway)

---

Well, either way the idea itself is quite self-revealing and the only problem is ambiguous syntax, notice:

@a: {1: 1};      // OK, ruleset
@b: (@a);        // OK, set @b to @a
@c: (@a) (@b);   // OK, array/list
@d: (@a) {2: 2}; // ?!, array or unnamed ruleset with one parameter?
// same goes if this to be used as a mixin arg

In other languages with such facility this problem is solved with some specific keyword/operators preceding such lambda (e.g. [] in C++ or just function in JavaScript).

[rjgotten]

Just in case this is not ugly hack but well defined language facility.

When I mention it being a 'hack', I specifically mean that it seems hacked into the existing language desgin (to facilitate return values as a later addition), rather than something that was thought about up front. I don't mean the actual code is of low quality. Actually; the LESS parser and AST are quite well done. (Tip of the hat for that.)

However, the fact that it's well-defined and well-engineered doesn't make it less ugly when used. It's a language feature that is completely counter to intuition for most, as no other mainstream language does this.

the only problem is ambiguous syntax
In other languages with such facility this problem is solved with some specific keyword/operators preceding such lambda

May I suggest @a: (@b) => { b : b } ?
It's reminiscent of both C#'s lambda delegates and JavaScript's ES6 Harmony arrow notation for functions with preserved lexical scope. Provided you place detached rulesets at the head of the types the parser tries to apply for expressions (which I think it already is), this should result in a deterministic parsing without ambiguities.

And if you really wanted to have a list with an explicit => symbol in there, well; there's always ~"=>" as an escape hatch. (It's not like you don't already have this problem with calc() to some degree.)

[seven-phases-max]

rather than something that was thought about up front.

(Though we're quickly going offtopic - Yes, it was not something thought of the earlier Less days but today it still remains the only way to "return" something from something in Less (since the "function" facility is still somewhat neglected, though actually the whole thing is not limited to returning variables). So I insist :) that "parent scope leak" has nothing to do with lambdas, after all lambdas do not return anything at all. And the rest is another unrelated story).

---

@a: (@b) => { b : b } - Yes, could be something like this (though personally I extremely don't like => :)

[matthew-dean]

Per the discussion in #1943, and also related to passing mixins by reference (issue # ?), I would suggest this syntax:

.mixin(@args) {
    box-shadow+: @args black;
}
a {
    each(10px 10px, -20px -20px, .mixin);
}

...equal to...

.mixin(@args) {
    box-shadow+: @args black;
}
@list: 10px 10px, -20px -20px;
a {
    each(@list, .mixin);
}

...equal to...

@list: 10px 10px, -20px -20px;
a {
    each(@list, (@args) {
      box-shadow+: @args black;
    });
}

However, there's no reason that you shouldn't be able to use the same construct for user-defined mixins: .for(@list, .mixin); and do whatever you want with the list / mixin parameters.

To be accurate, this is an extension of mixins / parameters, and not detached rulesets, and passing mixins by reference has been discussed elsewhere (although I couldn't find it with a brief search).

[seven-phases-max]

and passing mixins by reference has been discussed elsewhere (although I couldn't find it with a brief search).

It was mentioned in #965 (comment) and then in more details discussed #1648 (comment) and following comments.

[matthew-dean]

Per separate discussion with @plugin, this now seems like an ideal candidate to close in favor of a user-defined function via @plugin.

[matthew-dean]

Also, this is strangely relevant to #1505 which I just commented on, because we're demonstrating passing a CSS list to a custom function.

[seven-phases-max]

this now seems like an ideal candidate to close in favor of a user-defined function via @plugin

Note that currently you can neither pass identifiers like .mixin to a function (not allowed by the parser) nor you can call a function w/o assigning its result to something... So, no, for now it's simply impossible to implement such each via plugin.

[matthew-dean]

So, no, for now it's simply impossible to implement such each via plugin.

Oh. Damn. Welll.... wouldn't it seem like a good candidate for adding more flexibility for plugins? What I mean is, it's a narrow use case, and I think we had talked about narrow use cases as candidates for user-defined plugins. OR optional core plugins (which isn't defined yet).

So, to me, if this went in, it's either expanding core in one way or another. One would be specific to this use case, and one would be expanding plugins to support scenarios like this use case.

[rjgotten]

@seven-phases-max
So, no, for now it's simply impossible to implement such each via plugin.

Oh... I wouldn't be too sure about that.

[matthew-dean]

Oh... I wouldn't be too sure about that.

Yes, but in your example, it seems you're only doing a partial solution with the plugin, and then doing the other part in a recursive mixin. My question was basically if a plugin could do this (from one of my examples above:

@list: 10px 10px, -20px -20px;
a {
   @plugin "awesome-list-functions-which-contains-each";
    each(@list, (@args) {
      box-shadow+: @args black;
    });
}

Based on your gist, it looks like you're agreeing with @seven-phases-max. No?