Re: [Caml-list] Notation for currying

[Gabriel Scherer <gabriel.scherer@gmail.com>]

The initial discussion was more about the difference in readability
between two syntaxes for fully-applied functions or constructors,
  f(x, y, z), C(x, y, z)
or
  f x y z, C x y z
I find the latter more readable in many settings, in particular where
functions or constructors are nested. One typical example would be the
"balance" functions for Okasaki-inspired red-black trees, for example
https://www.lri.fr/~filliatr/ftp/ocaml/ds/rbset.ml.html

Compare
    | Red (Red (a,x,b), y, c), z, d ->
        Red (Black (a,x,b), y, Black (c,z,d))
with
    | (Red (Red a x b) y c), z, d
        Red (Black a x b) y (Black c z d)

Note that using this syntax does not in itself require supporting
partial application, even though they are naturally linked in the most
common reading of this syntax as nested unary application.

Now, to your question of "do we need to make it easy to partially
abstract over the last parameter of the function", I think I would
agree with you that this is not essential (especially when the syntax
for abstraction is already lightweight). However, having a good syntax
for application is a rather subtle balance to strike that may require
cooperation of several distinct syntactic elements -- in particular
when you also want to support named parameters (or have a lightweight
enough syntax for records or named tuples that looks like named
parameters). I like named parameters as they often improve the
robustness of APIs -- lightweight records are even better because they
can be both passed and returned.

Finally, in Mezzo ( http://protz.github.io/mezzo/ ) there is a cute
trick that I have not seen anywhere else, and I wonder whether it is
an extraordinary (but ancedotal) coincidence or something that should
be reused. The syntax for function parameters in function prototypes
(declarations, signature items)

   val concat: [a] (consumes list a, consumes list a) -> (list a)

and in function definitions

  val concat [a] (consumes xs: list a, consumes ys: list a): list a =
    ...

is exactly the same.

(See http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-types
, http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-definitions
)

This is only possible because the language has just enough dependent
types to make it natural to name all function parameters in their
types, and even do deep pattern-matching on an argument directly from
the type definition. It reminds us of the strange identification
between types and patterns in CDuce ( http://www.cduce.org/ ).

On Sat, Nov 21, 2015 at 7:05 PM, David Rajchenbach-Teller
<David.Teller@ens-lyon.org> wrote:
> As a side question, is currying really an important language feature? In
> my experience, it hinders readability and makes it harder to reason
> about types ("wait, is it weakly or strongly polymorphic? exactly which
> type variables were generalized?")
>
> After coding a number of years in languages without currying, I haven't
> found myself lacking this feature a single time.
>
> Cheers,
>  David
>
> On 21/11/15 18:24, Hendrik Boom wrote:
>> On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote:
>>>
>>> I personally believe that currified constructor syntax would be a better
>>> choice, and that using non-currified constructors is a historical mistake
>>> of SML/Caml. But I am also not convinced that efforts to change it today
>>> are worth the trouble, and prefer to concentrate on improving other parts
>>> of the OCaml ecosystem.
>>
>> Perhaps there should be explicit syntax for currying, such as
>>    f a b _
>> instead of
>>    f a b
>> That would permit currying in other argument positions:
>>    f a _ c
>> though I suspect _ may be the wrong symbol for the current language, and
>> I also suspect it's far too late tointroduce it in the current language.
>>
>> I have noticed that almost a the situations where the compiler thinks I
>> mean to curry I actually just left out a parameter by mistake.  The type
>> inferences it makes based on these errors usually occur elsewhere and
>> are truly mystifying.
>>
>> -- hendrik
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs