Comment by masklinn | Hacker News Reader

Comment by masklinn | Hacker News Reader

Parent Full thread

> Currying and partial application are really nice when you have a pipeline operator

Currying != partial application.

And while currying is useful in curried languages (to convert back from uncurried to curried), and partial application is useful period, the question is whether currying is useful, in general, in an uncurried language.

I don't think it is:

* You usually want to perform partial application, currying is an unnecessary intermediate step.

* Currying conflicts with rich "imperative" parameters e.g. overloading, default parameters, keyword parameters.

* Uncurried languages are usually imperative and effectful, that you have filled all the parameter spots does not mean you want to invoke the function.

Having a curried language is neat, and in curried languages converting back from uncurried to curried functions is tremendously useful. But it's not so for uncurried languages (which is most of them).

> which is why the partial application and pipeline operator proposals are so intertwined.

Again, partial application != currying. And pipeline operators can perform partial application (implicitly or explicitely) on their own. For a flagrant example, just see Clojure:

    (->> users
     (map :email)
     (sendEmail)
     (mapError (constantly "Error sending emails"))

I'm not sure I fully appreciate the distinction you're trying to make here: "currying != partial application". Can you clarify?

In particular I don't know what's meant by "curried" and "uncurried" languages

> I'm not sure I fully appreciate the distinction you're trying to make here: "currying != partial application". Can you clarify?

Currying is the conversion of an n-ary function into a chain of 1-ary function e.g. `fn(a, b, c) -> d` becomes `fn(a) -> fn(b) -> fn(c) -> d`.

Partial application is what it says on the tin, it only applies k parameters to the function returning an (n-k) parameters function, without actually running the function.

Currying is one method allowing partial application, but not necessarily the only one, or usually the best fit as it tends to not interact well with features like overloading, default parameters, keyword parameters, …

> In particular I don't know what's meant by "curried" and "uncurried" languages

Languages like Haskell, OCaml, or Elm are "curried" by default: when you define an n-ary function it's really just sugar for a chain of 1-ary functions; and the application of multiple arguments is similarly the implicit application of single arguments multiple times e.g.

    map : (a -> b) -> List a -> List b
    map f l =
      case l of
        [] -> []
        (h::t) -> (f h) :: (map f t)

can be called as

    map fn [1, 2, 3]

or

    (map fn) [1, 2, 3]

the semantics are identical, which is not the case in an uncurried language like Javascript or Python:

    map(fn, [1, 2, 3])

and

    map(fn)([1, 2, 3])

will behave very differently unless the implementer has taken special steps to handle this case e.g. dynamic behaviour based on an optional second parameter, overloading, etc…

> applies k parameters to the function returning an (n-k) parameters function, without actually running the function

What would be the use of this? Just delaying the execution of the function's side-effects?

I'll tip my hand: I'm working on a JS-like (and JS-targeted) language that I want to support partial-application/currying by default. Under the hood everything is represented in a curried way, but syntactically you can both define and invoke/partially-invoke functions with the more familiar syntax (commas). But this is fully superficial right now; it all happens at the parser level. Is there a downside to doing things this way?

If you come from typical oop background like java. Imagine there is a function has 5 parameters, and you need to to provide the first 3 first. Then later on you are using this partially applied function somewhere else. You can even reuse it later with different 2 params. Compare to class, it's just like how you initialize an object with certain values, then do something else with this object.

The downside is that curried functions make default, optional, and keyword parameters difficult to implement.

For defaults/optionals, given "fn f(x, y, z=10)", if "f(1, 2)" evaluates to "f(1)(2)", does that return a function or the result of "f(1)(2)(10)"? What if you have "fn f(x, y = 10, z)"? All of this is a lot easier if you can evaluate the full argument list at the time of function invocation.

As for keyword arguments, they just don't play well with any kind of enforced ordering.

Got it.

I wonder if that ambiguity could be resolved using contextual type info? I.e. if one of the two interpretations fits the expected type, use that. Otherwise, type-error.

Maybe that would be confusing, not sure.

Bagel?

I read your post yesterday. Good luck with your language!

Yes, thanks! :)

To be honest this comments section has me seriously reconsidering the "everything is partially-applicable by default" feature, haha.

In Standard ML and Haskell, all functions are curried by default -- they take a single argument, and the syntax for defining multiple-argument functions is just sugar for defining single-argument functions that return single-argument functions. That's reflected in this Haskell type signature for a function adding two integers:

   add :: Int -> Int -> Int

This is a function that takes one integer and returns a function which itself takes another integer and then finally returns an integer. Syntax sugar allows you to define it and call it like a single function.

An uncurried function in these languages is a function that takes multiple arguments as a tuple.

   add :: (Int, Int) -> Int

You don't see a lot of functions defined this way in Haskell because there isn't really any advantage to doing so in a lazy, pure language. It's more common in Standard ML from what I've seen, because SML is strict and impure.

At a deeper level currying is just a specific application of the Hom-tensor adjunction to the category of Sets. In particular the curried function is equivalent to the original. Partial function mappings is a restriction, and inherently not a injection. That is, generally the partial function is not in an equivalent Hom space to the original function.

そう言う事ですね〜ッ。は〜い

> Currying conflicts with rich "imperative" parameters e.g. overloading, default parameters, keyword parameters.

This doesn't contradict anything you said, but I think Idris is a language that curries everything and has default parameters.

https://docs.idris-lang.org/en/latest/tutorial/miscellany.ht...

Agreed, and I really with partial() was a builtin in Python, instead of having to fetch it from functools. partial() is useful regularly, and much more explicit/flexible than a lambda for this specific use case.

Reply on news.ycombinator.com