The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. And at the implementation side, it's not like map's flexibility came from nowhere. I wouldn't be surprised to find out that Clojure's `map` is just as verbose as Haskell's entire 'zip' family.

The whole concept of an `apply` function is a bit alien to me. I generally just call the damn function. Also, Haskell has an `apply` function. It's the `$` operator, defined thus (the first line is optional):

    `$` :: (a -> b) -> a -> b
    f $ x = f x

It helps that Haskell functions all have one argument (that with being curried by default). If you want several arguments, just apply them one by one:

    f $ x $ y

(This is sometimes used to avoid parentheses in some cases. I personally tend to just use the parentheses.)

> The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names.

Well, you have to select one of the zip functions in addition to map. Those are more names.

> Also, Haskell has an `apply` function. It's the `$` operator

That isn't what apply does. Apply takes a function and applies it to a list of arguments, (f x y) is equivalent to (apply f (list x y)).

> Apply takes a function and applies it to a list of arguments,

And the way to translate that in Haskell is to apply a single argument.

Haskell functions are not Lisp functions. Lisp functions take a list of arguments, so `apply` should apply to a list of argument. Haskell functions have one argument, so `apply` should apply to a single argument. That argument could be a tuple, by the way.

> Haskell functions are not Lisp functions. Lisp functions take a list of arguments, so `apply` should apply to a list of argument.

I understand how currying works, thanks, but that doesn't change the fact that $ is not equivalent to apply. A version of apply that dealt with curried functions would just have to fold over a list, and I don't think it could be properly generalised in Haskell's type system (but I"m not an expert at Haskell).

For your definition of apply, Lisp-1's don't have it, because as you said, you'd just call the damn function. Lisp-2's sort of have it, but it's called funcall. Regardless, your definition of apply is not what apply is in Lisp.

> I understand how currying works, thanks, but that doesn't change the fact that $ is not equivalent to apply.

You are seeing that a square hole isn't fitting a round peg, and accusing the hole of being too sharp. Or at least millstone did. Complaining about the absence of a Clojure like `apply` function in Haskell doesn't make any sense.

It would be like complaining about having to work around the lack of infix notation in Forth. Whoever does that need to let go of their old thinking habits, and rewire their brain to the new language. Not everybody can do that. Fewer still want to do that.

Now if someone says, "this real world problem is easier to solve in Clojure, in Haskell you have to jump through hoops", that would be different. For the present case, one would have to show how the absence of a proper Clojure like `apply` function could force anyone to jump from any hoops to solve any concrete problem.

> Regardless, your definition of apply is not what apply is in Lisp.

You've either said too much, or not enough. What "apply" does mean in Lisp, then?

>It's impossible to write down a Haskell function equivalent to Clojure's `apply`.

    apply :: Dynamic -> [Dynamic] -> Maybe Dynamic
    apply fn args =
        foldM dynApply fn args

Impossible may be strong misclassification.

Meh. I hardly consider

    max [a, b, c]

to be boilerplate.

You can certainly write variadic functions in haskell. The type looks funky and nobody will like you for it though.