Arc Forumnew | comments | leaders | submitlogin
2 points by cchooper 6142 days ago | link | parent

I've already come across multiple scenarios where automatic currying would have shortened my programs, and if the swap operator had been available, I'd have used it even more.

But I'm still not a fan of implicit currying. I think the behaviour would be too unpredicatable when mixing rest functions, optional arguments, apply and code generation together (for example, it's often useful to be able to pass 0 arguments to + when you are generating code, even if you'd never write that sort of thing manually).

My compromise: perhaps the [...] syntax could be adapted to do automatic currying. If you use _ then it has its normal behaviour, but if you don't then the function is curried automatically. Only required arguments can be passed to such a function, optional and rest arguments are ignored, so [+] simply evaluates to 0 (or a function that takes no arguments and returns 0).



3 points by almkglor 6142 days ago | link

By this I think you mean:

  [foo bar] => (fn rest (apply foo bar rest))
...?

-----

2 points by cchooper 6142 days ago | link

I'd originally envisioned that the function returned would be more strongly typed (ie. it would expand to (fn (x y z) ...) if foo takes 4 arguments) and that the function would be truly curried, so ([foo bar] baz) would also be a curried function if foo requires more arguments.

Now I think about it, the solution you've given would be perfectly adequate. The function will still fail on the wrong number of arguments, and I almost never need the other feature at all. It would also play friendly with optional and rest arguments.

-----

1 point by almkglor 6141 days ago | link

Hmm. It would be possible to modify 'make-br-fn on the arc-wiki.git for this.

-----