1943.loops.md

Well, I'm afraid this is another big story to discuss here. (My solution for such loops would be as in less/less.js#1648 (comment), in short: instead of having "native" each() hardcoded for a very limited particular pattern it would be more generic to allow to write your own mixins which you can adopt for your specific cases by allowing to call mixins by reference. And "more users" and stuff lead to another discussion -> "standard library" (which you can import implicitly if necessary to look "native") ;). Also notice that for the particular example above a separate mixin is only necessary to workaround specific args handling problem. And for a minimal loop, e.g.:

@import "for";

.mixin(@args...) {
    .for(@args); .-each(@v) {
        box-shadow+: @v black;
    }
}

a native each won't really help (or at least it won't make this less verbose). (Technically even more "clean-in-use" syntax is possible now using detached-rulesets but it has its own problems with scopes and hardcoded argument names).

Technically even more "clean-in-use" syntax is possible now using detached-rulesets but it has its own problems with scopes and hardcoded argument names.

Problem (mostly) solved
The trick is in unlocking a special mixin inside the detached ruleset, that is then called explicitly with arguments. This prevents the declaration scope from clobbering 'arguments' passed via the calling scope.

This actually works even in scenarios where calls are nested, e.g. iterating over 'lists of lists', as long as the defined signature for the special .\\ 'lambda mixin' is always the same (and thus the nested call overwrites the outer one).

Now if only I had a way of getting return values back out (detached rulesets don't bubble variables back up); then I'd be able to create map & reduce as well and get some real list manipulation boilerplate going. ^_^