Make all functions curried by default

[mstade]

If all functions are by default curried, then in many cases you can do partials without needing partial. Example:

exists = not(partial(eq, null))

... becomes ...

exists = not(eq(null))

Since eq needs at least two (well, in the current impl it only ever cares about two) arguments it would return a function rather than a result. That is, provided all functions are curried. There's an obvious performance hit to this, but I reckon it could be worth it for the lovely code it could produce.

[mstade]

Some interesting and relevant commentary over on SO.

[mstade]

Particularly this comment is enlightening:

Given (defn f ([x] 1) ([x y] 2)), what does (f true) yield? It must be 1, meaning it cannot be auto-curried as a partial application of the two-arity version.

This makes sense, although I'm not sure it's that confusing. Essentially, auto-currying would be the default last-resort when calling a function, as if there's a way the function could actually be applied that should be the default. If you truly do want a partial application, you can make that explicit by using partial. Interestingly, since partial acts as identity in case it didn't receive any arguments beside the function to be partially applied, this could be the default action in a predicate dispatch implementation. I.e., if there wasn't a full match (but could be, i.e. it satisfies some arguments but not all) then the result could be a partial application. If the match is invalid (i.e. an argument never satisfies the predicate) then it probably should error out though.

[sammyt]

I do really like the idea of currying by default, but I've always worried it would have some curious side effects due to how often the length of functions if lost during composition. Then there is the problem of variadic functions, when is the right time to invoke?

[mstade]

The length can be carried on, as I demonstrated through my funky use of eval (see #1) or possibly by other means, such as a funkis-specific property to carry metadata. I've been thinking about this for other reasons anyway. For instance, range is a seq, but right now the return is just a seq, there's nothing to suggest through reflection that it is a range. I experimented with introducing some sort of prototypical inheritance to reflect this relationship, but I think that breaks down when you have a one-to-many kind of derivation. Indeed, I don't think relationships are always of the I-have-this-thing or I-am-this-thing nature, but can also be I-am-somehow-related-to-this-thing. The canonical example here being I-am-a-composition-of-this-and-that-and-here's-some-relevant-information-about-our-relationship. I have no good suggestions as to how such an API might look, but I reckon it would enable such things as currying-by-default.

The other problem you mention – when should you invoke? – feels like a problem that is solved by drawing a line in the sand, and I feel that line should be drawn at as-soon-as-possible. That is, if a function is variadic, then invocation will happen as soon as all required parameters are provided. This might seem magical, but given functions really shouldn't change their API as often as I do right now (I'll get better, promise!) I don't think it's that big of a deal. If an API is known, it's easy to understand when it will be invoked if there's a hard and fast rule. If you need to curry optional (i.e. variadic) arguments, then you have to be explicit about it and make a composition.

All that said, I pretty much agree with your concerns, and am on the fence about this idea. It's probably one of those things you have to feel and get some experience with before making a call, but there's been at least a few situations where I feel having automatic currying would be so nice it's sugar and spice. Particularly comparison functions are nice when curried – e.g. gt, lt, eq, is etc. – but maybe I'm fooling myself into thinking this is a useful generic pattern, where really it should just be a generic comparison pattern.

Regardless of whether this is a generic pattern, it will require more function metadata than JavaScript currently offers. I'm currently investigating that while tinkering with multiple/predicate dispatch.

[mstade]

Still on the fence about currying by default. My current thinking is that it's so far removed from JavaScript convention that maybe it's just too magical. So I thought of something else today. What if all funkis functions supported currying by virtue of a property on the function itself. Here's an example:

const false = not.$(true)
false() //=> not(true)

What's happening here is that the special property $ returns a curried version of not. The currying here is left-to-right, but it could be right-to-left through another property:

const crange = cons.r$(range(5))
crange(5) //=> cons(5, range(5))

These names are terrible, but I think the idea might have legs. Another, rather wacky idea, is that there's only one currying method on funkis functions, and it allows the user to specify curried arguments out of order:

const _ = range.$.any
const even = range.$(0, _, 2)
even(10) //=> (0, 2, 4, 6, 8)

I think this could be really powerful, and as it'd be a property of a function, it can enable some pretty concise syntax while still not being magical.

Here's an example of some code that could benefit from such syntax:

const rest = once(when.$(not.$(done), lazy.$(next, length - 1)))

Note that when in this case is actually fully qualified, but using $ makes it lazy.

I don't think I dig using $ as the currying identifier. I reckon it reads poorly, but I have no other immediate suggestions.

[mstade]

Increasingly of the opinion that curried by default in a language like JavaScript is just too unconventional and magical, even for me.

[mstade]

All too much magic.