Proposal: lambdas (value-producing "variable" functions)

[extemporalgenome]

Currently LESS has good support for mixins that inject values and variables and mathematical expressions, but seemingly not value-producing functions that can be used in expressions similarly to how the builtin functions can be used. Since use of embedded JavaScript is considered an implementation detail, this could be used to portably handle many code deduplication needs, especially when the ability to specify functions to the LESS interpreter is tedious or impossible.

Proposed syntax (with trivial examples):

@div(@x, @y): (@x / @y);
@five: @div(10, 2);
@eight: @div(16, @div(6, 3));

The function body would be limited to valid LESS expressions including interpolation. Within a given scope, it would be reasonable that a name can either be defined as a variable or a @function, but not both. Although the above would be very useful on its own, it would additionally be useful to be able to utilize guard expressions, such as:

@div(@x, @y): (@x / @y);
@div(@x, 0): 0; // fallback value for errors

@min(@x, @y): @x;
@min(@x, @y) when (@y < @x): @y;
@max(@x, @y): @min(@y, @x);

Though the particular semantics and syntax are not important, in this subproposal, multiple definitions of the same name in the same scope augment the same @function, with precedence in order of: 1) arity, 2) pattern matching, 3) guard expressions. Rather than "all that apply", the most specific that applies would be chosen, and it should at least be a runtime error if multiple definitions at the same specificity apply. Definitions would never augment @functions with the same name from outer scopes, but would rather define a new @function that shadows the old one (just as variables do).

[lukeapage]

See #538