From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 622FF7F7B4
	for <caml-list@sympa.inria.fr>; Sat,  1 Feb 2014 15:52:32 +0100 (CET)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=pra; client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=mailfrom;
  client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mout.web.de) identity=helo;
  client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="postmaster@mout.web.de";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj0CAFoJ7VLU4xEMnGdsb2JhbABZvCmFUoEGFg4BAQEBAQYNCQkUKIIlAQEFJxM/EAsOCgklDwUoIYgDARjDAx+JaxePCQeDJIEUBJRCg2eGMhKPDA
X-IPAS-Result: Aj0CAFoJ7VLU4xEMnGdsb2JhbABZvCmFUoEGFg4BAQEBAQYNCQkUKIIlAQEFJxM/EAsOCgklDwUoIYgDARjDAx+JaxePCQeDJIEUBJRCg2eGMhKPDA
X-IronPort-AV: E=Sophos;i="4.95,760,1384297200"; 
   d="scan'208";a="56427360"
Received: from mout.web.de ([212.227.17.12])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Feb 2014 15:52:31 +0100
Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb103)
 with ESMTPSA (Nemesis) id 0Lh6M7-1VVNgu00FL-00oY7q for <caml-list@inria.fr>;
 Sat, 01 Feb 2014 15:52:31 +0100
Received: from mrvn by frosties.localnet with local (Exim 4.80)
	(envelope-from <goswin-v-b@web.de>)
	id 1W9bvq-0000W1-9Y; Sat, 01 Feb 2014 15:52:30 +0100
Date: Sat, 1 Feb 2014 15:52:30 +0100
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Arnaud Spiwack <aspiwack@lix.polytechnique.fr>
Cc: OCaML Mailing List <caml-list@inria.fr>
Message-ID: <20140201145230.GB1783@frosties>
References: <CAN6ygO=D8x=6MM+=+xG30p1LNn5vj3KnYNfSE5oU+6rMCEXhMw@mail.gmail.com>
 <20140121094939.GA13578@frosties>
 <CAN6ygO=J3SQeyHJyw+eBfLtrZ1W2d59Nc7XW0o8N8GDGwLzz5Q@mail.gmail.com>
 <20140123092009.GA20624@frosties>
 <CAMoPVjf3FQcw9yEMH9Dz80JPpTa8yLhDruN9_3LRhhN06De6ow@mail.gmail.com>
 <20140127093204.GA24902@frosties>
 <CAMoPVjcbiG=b2D+q2LV5LRjaV2c17VOOocFkOQ4w2Df+v-zoKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMoPVjcbiG=b2D+q2LV5LRjaV2c17VOOocFkOQ4w2Df+v-zoKg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID:  V03:K0:a4HFnpSCn40HuGZKs4ehRCi2XxQCuAt3wvqiN381G1Pq4dGaVu1
 rYhgYVxPVtiswl0ffn73+5309RlCeB7Hyokxw1W2J1saqdEmvk21KyehJhRFhxxbmwbJdww
 /rfxvlCbqbGoGMhbHcn2CDa7ts0clP3jtYh2BlQfGIs2mVhKUL4BBV22KVbobOX++YPOd2G
 MJRcIjpEZLzQ4dpFuIRzA==
Subject: Re: [Caml-list] Purity in ocaml

On Tue, Jan 28, 2014 at 10:21:20AM +0100, Arnaud Spiwack wrote:
> > Do you mean something like this?
> >
> > let g = function 0 -> raise G | n -> n
> > let f = function 1 -> raise F | n -> n
> >
> > map f (map g [1;0]) ===> raise G
> > map (f %> g) [1;0]  ===> raise F
> >
> > It is true, the exception prevents any optimization that would reorder
> > two functions that both throw an excepition.
> 
> 
> Precisely
> 
> 
> > But many other
> > optimizations are still possible, e.g. common subexpression
> > elimination:
> >
> > let n =
> >   let x = f (g 1) in
> >   let y = g 1 in
> >   x + y
> >
> > ==>
> >
> > let n =
> >   let t = g 1 in
> >   let x = f t in
> >   let y = t in
> >   x + y
> >
> 
> To some degree:
> 
> let n =
>   let x = f (g 1) (h ()) in
>   let y = g 1 in
>   x+y
> 
> is a different program than
> 
> let n =
>   let t = g 1 in
>   let x = f t (h ()) in
>   let y = t in
>   x+y
> 
> As it reorders (g 1) and (h ()). I think the rule is something like: when
> the program is in monadic form, and you have a call to e, you can factor in
> every subsequent calls to e. Which I guess is good enough. But I would tend
> to believe deforestation would be tremendously more useful than common
> expression elimination.

Does it reorder? I would expect these two to be equivalent

    let x = f (g 1) (h ()) in

and

    let f2 = f (g 1) in
    let x = f (h ()) in

and in the second case the order is clearly g before h.

If the order is indeed to evaluate the last argument first then

    let t1 = h () in
    let t2 = g 1 in
    let x = f t2 t1 in
    let y = t2 in
    x + y

It's not hard to preserve the order whatever it may be.

MfG
	Goswin