From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C88A9BBAF for ; Wed, 10 Nov 2010 16:18:20 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAHdG2kxV6aAZmGdsb2JhbACDOZ4kWBUBAQIBCAkMBxEirHeQeoEigzVzBIpXgwyCbg X-IronPort-AV: E=Sophos;i="4.59,178,1288566000"; d="scan'208";a="78328424" Received: from outgoing-smtp.namesco.net ([85.233.160.25]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2010 16:18:20 +0100 Received: from [192.168.0.13] (helo=scary.hosts.co.uk) by outgoing-smtp.namesco.net with esmtp (Exim 4.67) (envelope-from ) id 1PGCRF-0003wU-QO; Wed, 10 Nov 2010 15:18:18 +0000 Received: from root by scary.hosts.co.uk with local (Exim 4.69) (envelope-from ) id 1PGCRG-0000dm-QW; Wed, 10 Nov 2010 15:18:18 +0000 To: , , , Cc: From: Reply-To: Subject: =?utf-8?q?Re=3a=20=5bCaml=2dlist=5d=20Infix=20function=20composition=20operator?= MIME-Version: 1.0 X-Mailer: Namesco Webmail v3.0 Message-ID: <1289402298589@names.co.uk> Date: Wed, 10 Nov 2010 15:18:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-namescosender: 0 2002 X-namesco: 192.168.0.171 X-Spam-Score: -1.0 (-) X-Spam: no; 0.00; infix:01 parser:01 combinators:01 ocaml:01 val:01 val:01 parser:01 combinators:01 compilation:01 mls:01 haskell:01 ocaml:01 ocamlyacc:01 camlp:01 cheers:01 Fascinating! I do use parser combinators myself, and find myself having to use the eta-expanded form, like you say. Thanks for that explanation. Mark. on 10/11/10 2:20 PM, Jon Harrop wrote: > In OCaml, the value restriction leads to non-generalized type variables ('_a > etc.) if you try to define functions like: > > # let ( << ) f g x =3D f(g x);; > val ( << ) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b =3D > > # let cons h t =3D h::t;; > val cons : 'a -> 'a list -> 'a list =3D > > # cons << cons;; > - : '_a -> ('_a list -> '_a list) list -> ('_a list -> '_a list) list =3D > > > 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 =3D (cons << cons) x;; > val cons2 : 'a -> ('a list -> 'a list) list -> ('a list -> 'a list) list =3D > > > But a pipeline is prettier: > > # let ( |> ) x f =3D f x;; > val ( |> ) : 'a -> ('a -> 'b) -> 'b =3D > > # let cons2 x =3D x |> cons |> cons;; > val cons2 : 'a -> ('a list -> 'a list) list -> ('a list -> 'a list) list =3D > > > 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.