caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jonathandeanharrop@googlemail.com>
To: <mark@proof-technologies.com>,
	<jonathandeanharrop@googlemail.com>, <yminsky@gmail.com>,
	<arlen@noblesamurai.com>
Cc: <caml-list@inria.fr>
Subject: RE: [Caml-list] Infix function composition operator
Date: Wed, 10 Nov 2010 14:13:14 -0000	[thread overview]
Message-ID: <022001cb80e1$6afeee00$40fcca00$@com> (raw)
In-Reply-To: <1289396667803@names.co.uk>

In OCaml, the value restriction leads to non-generalized type variables ('_a etc.) if you try to define functions like:

# let ( << ) f g x = f(g x);;
val ( << ) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>

# let cons h t = h::t;;
val cons : 'a -> 'a list -> 'a list = <fun>

# cons << cons;;
- : '_a -> ('_a list -> '_a list) list -> ('_a list -> '_a list) list = <fun>

This is a silly example but you are most likely to hit this problem in practice in the context of parser combinators. Due to JIT compilation, F# cannot relax the value restriction so that does not even compile.

In MLs, you usually want the eta-expanded form:

# let cons2 x = (cons << cons) x;;
val cons2 : 'a -> ('a list -> 'a list) list -> ('a list -> 'a list) list =
  <fun>

But a pipeline is prettier:

# let ( |> ) x f = f x;;
val ( |> ) : 'a -> ('a -> 'b) -> 'b = <fun>

# let cons2 x = x |> cons |> cons;;
val cons2 : 'a -> ('a list -> 'a list) list -> ('a list -> 'a list) list =
  <fun>

This is one advantage of Haskell over OCaml/F#. However, I don't see it as a useful advantage in practice because parser combinators are so tedious during development (they require constant attention as types evolve): you want code generation like ocamlyacc or camlp4. OCaml is a very strong contender here, of course.

Cheers,
Jon.

> -----Original Message-----
> From: mark@proof-technologies.com [mailto:mark@proof-technologies.com]
> Sent: 10 November 2010 13:44
> To: jonathandeanharrop@googlemail.com; yminsky@gmail.com;
> arlen@noblesamurai.com
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] Infix function composition operator
> 
> So how does value restriction affect things here?  (excuse my lack of
> knowledge)
> 
> One thing about using a pipeline like this is that it relies on '|>'
> being
> left-associative (which it is due to OCaml's convention on operators
> that
> start with "|").
> 
> Mark.
> 
> 
> on 10/11/10 12:52 PM, Jon Harrop <jonathandeanharrop@googlemail.com>
> wrote:
> 
> > A pipeline operator is usually preferred over function composition in
> impure
> > languages like OCaml and F# due to the value restriction. For
> example,
> your
> > example would be written in F# as:
> >
> > x |> op1 |> op2 |> op3 |> op4 |> op5
> >
> > This style is very common in F#, particularly when dealing with
> collections.
> >
> > Cheers,
> > Jon.
> >
> >> -----Original Message-----
> >> From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-
> >> bounces@yquem.inria.fr] On Behalf Of mark@proof-technologies.com
> >> Sent: 10 November 2010 07:00
> >> To: yminsky@gmail.com; arlen@noblesamurai.com
> >> Cc: caml-list@inria.fr
> >> Subject: Re: [Caml-list] Infix function composition operator
> >>
> >> on 10/11/10 3:45 AM, yminsky@gmail.com wrote:
> >>
> >> > This is probably a minority opinion, but I have written and read
> >> quite a
> >> lot
> >> > of OCaml code over the years, and I've seen surprisingly few
> >> effective
> >> uses
> >> > of the composition operator.  Somehow, I usually find that code
> that
> >> avoids
> >> > it is simpler and easier to read.
> >>
> >> I agree that using a composition operator can make the code obtuse,
> and
> >> so
> >> should not be overused.  But it's incredibly useful for certain
> >> situations:
> >>
> >> 1) If you are performing a long chain of composed operations, it
> avoids
> >> nested bracketing piling up.
> >>
> >> For example:
> >>       (op5 <<- op4 <<- op3 <<- op2 <<- op1) x
> >> Instead of:
> >>       op5 (op4 (op3 (op2 (op1 x))))
> >>
> >> This sort of thing happens quite a lot in certain applications, e.g.
> in
> >> language processing, to get at subexpressions.
> >>
> >> 2) Creating an anonymous function to be passed as an argument, it
> >> avoids
> >> explicitly mentioning arguments of that function.
> >>
> >> This sort of thing can happen a lot in functional programming
> >> generally.
> >>
> >> For example:
> >>       List.map (op2 <<- op1) xs
> >> Instead of:
> >>       List.map (fun x -> op2 (op1 x)) xs
> >>
> >> Mark Adams
> >>
> >> _______________________________________________
> >> Caml-list mailing list. Subscription management:
> >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> >> Archives: http://caml.inria.fr
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> >
> >
> >


  reply	other threads:[~2010-11-10 14:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10 13:44 mark
2010-11-10 14:13 ` Jon Harrop [this message]
2010-11-10 16:10   ` Stephan Tolksdorf
2010-11-10 17:41     ` Jon Harrop
2010-11-10 18:52       ` Stephan Tolksdorf
  -- strict thread matches above, loose matches on Subject: below --
2010-11-10 15:18 mark
2010-11-10  6:59 mark
2010-11-10 12:51 ` Jon Harrop
2010-11-14 18:20   ` Till Varoquaux
2010-11-10  3:19 Arlen Christian Mart Cuss
2010-11-10  3:45 ` [Caml-list] " Yaron Minsky
2010-11-10  4:37   ` Arlen Christian Mart Cuss
2010-11-10 10:06   ` DS
2010-11-10 13:23 ` Michael Ekstrand

Reply instructions:

You may reply publicly 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='022001cb80e1$6afeee00$40fcca00$@com' \
    --to=jonathandeanharrop@googlemail.com \
    --cc=arlen@noblesamurai.com \
    --cc=caml-list@inria.fr \
    --cc=mark@proof-technologies.com \
    --cc=yminsky@gmail.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).