caml-list - the Caml user's mailing list
 help / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: David.Teller@ens-lyon.org
Cc: Hendrik Boom <hendrik@topoi.pooq.com>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Notation for currying
Date: Sat, 21 Nov 2015 19:55:25 +0100
Message-ID: <CAPFanBEc=TFD2b9MA8+JofK6dHpT5zvwzDT2qTLuxhjSxCYqFQ@mail.gmail.com> (raw)
In-Reply-To: <5650B27F.5000701@ens-lyon.org>

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

  reply index

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06  9:33 [Caml-list] Newbie comment on constructor syntax Soegtrop, Michael
2015-11-06 10:04 ` Nicolas Ojeda Bar
2015-11-06 10:31 ` Francois Berenger
2015-11-06 12:20   ` Soegtrop, Michael
2015-11-06 12:34     ` Gabriel Scherer
2015-11-06 13:09       ` Soegtrop, Michael
2015-11-06 14:10         ` Ashish Agarwal
2015-11-06 15:19           ` Soegtrop, Michael
2015-11-06 15:22             ` Ashish Agarwal
2015-11-21 17:24       ` [Caml-list] Notation for currying Hendrik Boom
2015-11-21 17:42         ` Gabriel Scherer
2015-11-21 18:06         ` David Rajchenbach-Teller
2015-11-21 18:56           ` Gabriel Scherer [this message]
2015-11-06 12:29 ` [Caml-list] Newbie comment on constructor syntax Jonas Jensen
2015-11-06 12:46   ` Soegtrop, Michael
2015-11-06 12:55     ` Gabriel Scherer
2015-11-08 21:17 ` Florian Weimer
2015-11-08 22:51   ` Norman Hardy
2015-11-09  6:27     ` Florian Weimer
2015-11-09 13:27       ` Stefan Monnier
2015-11-09  8:10     ` Soegtrop, Michael
2015-11-09 10:00       ` Hendrik Boom
2015-11-09 10:17       ` Alain Frisch
2015-11-09 10:35         ` Andreas Rossberg
2015-11-09 12:28           ` Alain Frisch
2015-11-09 17:33           ` Alain Frisch
2015-11-09 18:09             ` Gabriel Scherer
2015-11-09 18:16               ` Andreas Rossberg
2015-11-09 21:12                 ` Gabriel Scherer
2015-11-09 22:06                   ` Alain Frisch
2015-11-09 22:27                   ` Andreas Rossberg
2015-11-09 22:57                     ` Jeremy Yallop
2015-11-10  0:11                   ` Hendrik Boom
2015-11-10  8:27                   ` Soegtrop, Michael
2015-11-10 10:26                     ` Romain Bardou
2015-11-10 10:44                       ` Alain Frisch
2015-11-10 10:55                         ` Romain Bardou
2015-11-10 13:17                           ` Alain Frisch
2015-11-10 13:41                             ` Romain Bardou
2015-11-10 14:01                               ` Alain Frisch
2015-11-13 15:36                           ` Romain Bardou
2015-11-10 11:17                         ` Soegtrop, Michael
2015-11-10 14:11                     ` Hendrik Boom
2015-11-10 14:40                       ` immanuel litzroth
2015-11-10 15:30                       ` Soegtrop, Michael
2015-11-10 17:28                         ` Gerd Stolpmann
2015-11-09 20:32               ` Alain Frisch

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPFanBEc=TFD2b9MA8+JofK6dHpT5zvwzDT2qTLuxhjSxCYqFQ@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=David.Teller@ens-lyon.org \
    --cc=caml-list@inria.fr \
    --cc=hendrik@topoi.pooq.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox