Allow parametrized mixins as detached rulesets to form 'lambdas'

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.)

[matthew-dean]

$@ works!? I had no idea! I thought it was nixed! That makes me so happy!

Ha, yeah I slipped it in bug fixes before I released 3.5. ^_^

[rjgotten]

I’d think “anonymous” would suggest “not author-callable”

The “anonymous” in “anonymous function” comes from the fact that it is constructed without its own named reference.

Without its own named reference, it cannot be directly accessed through name by code at other locations. In that sense, such a function is “not directly author-callable,” but is still callable if the author assigns the original function reference to a variable.

So yes; “anonymous mixin” is definitely the correct terminology here.