An instance of the normal application rule (in standard notation) for curried function is:

f : (. t1, t2) => t   e1:t1   e2:t2
-----------------------------------
         f(. e1, e2) : t

This PR provides an additional rule, one instance being:

f : (. t1, t2) => t   e1:t1
---------------------------
    f(e1) : (. t2) => t

One immediate consequence is that instead of having a library function such as raise : exn => 'a, one can provide instead an uncurried function raise : (. exn) => 'a.
Any pre-existing client code that uses raise(E) still works because of the new rule.
In addition, new uncurried code can call the same function with raise(. E).

This opens the possibility of uncurrifying libraries without affecting existing code, for the most part, and have new uncurried code written in natural style take advantage of the uncurried definitions. One case where there is no free lunch are callbacks, as in List.map where two versions still need to be provided if two uses are required.

Now switching to uncurried by default notation. The same new rule, just written in uncurried by default notation, looks like this:

f : (t1, t2) => t  e1:t1
------------------------
  f(. e1) : t2 => t

One way to read this rule is: one can opt into partial application by using the dot notation. The net effect is that no curried types are ever created if one only uses uncurried functions and partial application.