cyclical placeholders

[davidchambers]

@Avaq proposed cyclical placeholders (for Ramda initially), and has since published a gist with a reference implementation and tests!

#	From	To	Normal	Alternative
1	a → b → c	a → c	f(_, b)(a)	f(_, b)(a)
2	a → b → c	b → a → c	nope	f(_)(b, a)
3	a → b → c → d	b → d	f(a, _, c)(b)	f(a, _, c)(b)
4	a → b → c → d	a → b → d	f(_, _, c)(a, b)	f(_, _, c)(a, b)
5	a → b → c → d	a → c → d	f(_, b)(a, c)	f(_, b, _)(a, c)
6	a → b → c → d	b → a → d	nope	f(_, _, c, _)(b, a)
7	a → b → c → d	c → a → d	nope	f(_, b)(c, a)
8	a → b → c → d	c → b → d	nope	f(a, _)(c, b)
9	a → b → c → d	b → c → a → d	nope	f(_)(b, c, a)
10	a → b → c → d	c → a → b → d	nope	f(_, _)(c, a, b)
11	a → b → c → d	c → b → a → d	nope	nope
12	a → b → c → d	b → a → c → d	nope	nope

The alternative has another advantage: You can supply the placeholders in curried fashion, something which is impossible with the normal semantics:

f(a, b, c) === f(_, _, c, _)(b, a) === f(_)(_)(c)(_)(b)(a) === f(_, _, c, _, b, a)

Notes

• The alternative method almost provides the full power of rearg, except for cases like 11 and 12. These kinds of cases would become more common as the arity of the function increases.
• The alternative method has exactly the same syntax for the majority of use-cases. Note that only 5 differs. These differences will become more abundant as the arity of the function increases.
• The alternative method has more consistent behavior; there's no difference between calling your function f(_)(_)(_) or f(_, _, _).

Adopting these semantics would gain us a lot and lose us very little. Does anyone object to this change?

/cc @buzzdecafe, @CrossEye

[buzzdecafe]

could the "normal" column for 2 a → b → c to b → a → c be simply flip(f)? Or maybe a flip column would be useful for comparative purposes

[davidchambers]

could the "normal" column for 2 a → b → c to b → a → c be simply flip(f)?

f(_, y, x) would be equivalent to C(f, y, x), yes. :)

The fact that cyclical placeholders give us flip/C in addition to the benefits of the current placeholder semantics indicates that they're more powerful (and perhaps more general).

Or maybe a flip column would be useful for comparative purposes

I agree, though I don't want to modify a quote. Perhaps Aldwin will update the original document. :)

[Avaq]

Woah there. I have more then just a reference implementation. I have a highly performance optimized, ready to use (unfortunately untested) implementation laying about somewhere! Let me dig it up.

[Avaq]

I was going to add tests and release this code as a package called furry, but I never got to it. I still have some good uses for a stand-alone currying lib, but I guess Sanctuary won't be able to use it directly, because of it's type-checking-currying-combo. Here's the code anyway, might be of use.

[Avaq]

Or maybe a flip column would be useful for comparative purposes -- @buzzdecafe

There's a rivision of the gist where I attempted to name each use-case. flip is in there. But eventually I removed the column because the table was growing too wide and names were getting harder to come by. ;)

I guess I'll just put it under "Notes".

[davidchambers]

Why isn't this basic “R.useWith” working properly?

The OP had written R.map(R.__) expecting it to "flip" the function. This suggests the cyclical behaviour is intuitive.

[CrossEye]

Mostly it makes me want to get rid of the placeholders as best we can.

And I'm not sure that the thought was that fn(__) flipped the function so much as that the placeholder is treated as a normal argument, so that since fn(x, y) ~= fn(x)(y) we can just substitute __ for x.

[Avaq]

I released my code under WTFPL. Anyone is free to take the code and use it in their libs.

[Avaq]

I believe this can be closed, because we're moving away from Ramda style currying in #179. I myself now believe that although cyclical placeholders are superior to regular placeholders - no placeholders are even better.