liorean at gmail.com
Fri Oct 16 22:47:05 UTC 2015
Well, as I see it, there is nothing that currently could be done with
regards to this if what you desire is to make it automatic.
What we could add are various ways of manually doing this, either as
syntax or as library extensions. And then comes the question of which
way and what exactly.
Are you talking about pure currying, that is, taking a multiple
parameter function and turning if into a series of it's arity many
single argument functions, i.e:
Are you talking about partial application,i.e:
And where any zero argument applications return the same function?
Is it currying or partial application you want? How do you handle
functions that take rest parameters, optional parameters, true
variadric functions like e.g. sum that is theoretically zero to
infinity arity? or whose arity with regards to partial application
(and not the formal functionobject.length arity) is dependent on the
contents of those arguments? How do you handle this value? How do you
handle arguments object? How do you handle named autorecursion? Do you
want to be able to do this for constructors as well? How about getters
and setters? Generators? How do you handle extremely high argument
counts? How do you handle defaults? How do you handle argumentless
Automating this is in the language as it is would be a no-go for
backwards compatibility reasons I would say. Possibly you could have
manual currying, like what I wrote for rosettacode here:
Note the several caveats in that code. And sure, you could add syntax
for it instead of using a function like I do there, but it's still the
same explicit action, so would syntax really help in any way?
And for several cases you'd actually have to make a decision and stick
to it, or implement all the alternatives. Just see how I had to deal
with rest arguments there, because without two different versions, I
would have to choose either to handle rest arguments always with a
separate application, or never. If you want partial application,
that's slightly different in a few ways, but not notably harder.
David "liorean" Andersson
More information about the es-discuss