"Curry: Even though pedantics call curry a partial apply, we're continue to call it currying Need Func.curry &f(...) on a Func instance is syntax sugar for f.curry(...)"

What has curring to do with partial application? Currying means converting one function taking multiple arguments into a function returing functions so each function just recives one argument.

// Uncurried (one function accepting two Ts and returning a T)
(T, T) -> T

// Curried (a function accepting a T returing a function accepting a T returning a T
T -> T -> T

After you curryed a function you can partialy apply it. But curring itself is not partial application.

Int uncurriedAdd(Int x, Int y)
{
   return x + y
}

Int curryedAdd(Int x)
{
   return |Int y| { return x + y }
}

You see nothing is partially applied to curry a function.

If the language would have a more powerfull typesystem with parametric polymorphism (also known as generics) you could write a curry-function your own (using some a bit fan like pseudocode, T->U meaning the type of a function reciving a T and returning a U):

// recives a function reciving a T and a U and returning a V
// returns a function returning a function
T->U->V curry[T, U, V] ((T, U)->V function)
{
   return |T x| { return |T y| { return function(x, y) } }
}

Now one could convert a function into a curried function:

curriedAdd := curry(uncurriedAdd)

But you said in your documents that you don't want your language to become that powerfull.

We've definitely debated if curry is the right term. There is a lot of confusion b/w curry and partial application. At the time we defined the feature, the Wikipedia topic was wrong, Python was going to call it curry, and Groovy calls it curry still (as far as I know). But if there is strong objection to the terminology, then we should change it.

Regarding generics - you are right, we made a big design trade-off by not including user defined generics to keep the language simpler.