> A usual workaround in such situations is to first partially apply your
> function to the (n-1) first arguments, as this should cause no
> side-effects. Since I suppose you are really talking about
>
>  transform f x y
>
> you should rather write
>
>  transform (f x) y
>

It indeed helps, forces to invoke  function f (with two parameters)
inside transform.

We know how to use transform properly, passing a function with only
one parameter or passing curried f with n-1 parameters.

But what if we were providing a library, users still might use it
incorrectly, thus it will cause a runtime error rather than compile
time error.

I know it's difficult and (even) impossible to do this kind of compile
time checking,
zip1, zip2, zip3, .... zip7, mentioned by blue storm, might be a
better solution.

Ask users to follow the convention,
use zip1 if f has one parameter
use zip2 if f has two parameters
....
use zip7 if f has seven parameters

OR

transform only accepts function with one parameter, multiple
parameters must be passed as a touple type like (a, b, c)


> Note that this will not work properly if partial applications of f cause
> side-effects (i.e. f is actually "fun x -> ...; fun y -> ...").
> This is pretty rare, but I believe this is the case for printf for
> instance.
>
> Jacques Garrigue
>