From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jeremy.yallop@ed.ac.uk>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled 
	version=3.1.3
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by yquem.inria.fr (Postfix) with ESMTP id 5B1FFBC69
	for <caml-list@yquem.inria.fr>; Tue,  3 Jul 2007 11:25:40 +0200 (CEST)
Received: from bdmail1.accesst.com (pop.bulldoghome.com [83.245.1.230])
	by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l639PdGZ005339
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)
	for <caml-list@inria.fr>; Tue, 3 Jul 2007 11:25:40 +0200
Received: from host-84-9-233-105.bulldogdsl.com ([84.9.233.105] helo=[192.168.123.191])
	by bdmail1.accesst.com with esmtpa (Exim 4.50)
	id 1I5eUP-0001qO-VP; Tue, 03 Jul 2007 10:16:06 +0100
Message-ID: <468A16DF.5070506@ed.ac.uk>
Date: Tue, 03 Jul 2007 10:29:03 +0100
From: Jeremy Yallop <jeremy.yallop@ed.ac.uk>
User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070618)
MIME-Version: 1.0
To: Arnaud Spiwack <aspiwack@lix.polytechnique.fr>
Cc: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] ANN: pattern guards
References: <Pine.LNX.4.64.0706291518250.15944@rydell.inf.ed.ac.uk>	<1183141562.5305.19.camel@rosella.wigram>	<468555F9.7090005@ed.ac.uk>	<1183176563.8849.27.camel@rosella.wigram> <4685DFA0.7000306@lix.polytechnique.fr>
In-Reply-To: <4685DFA0.7000306@lix.polytechnique.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Miltered: at concorde with ID 468A1613.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; 'with:98 'with:98 compromising:98 wrote:01 arnaud:01 caml-list:01 constructor:01 precisely:01 expression:02 match:02 evaluates:02 variables:02 confusing:02 seems:03 let:03 

Arnaud Spiwack wrote:
> A (too) quick answer could of course be: "in the absence of a 'with 
> clause', it is considered the identity 'with clause'". But I'm not sure 
> it's that satisfying in practice. (it precisely and accurately adresses 
> this very case John Skaller is raising, but not the same example with an 
> additional variable in each constructor...).
> 
> A suitable solution for nested guarded patterns could be, instead of 
> saying "all the branches of the or-pattern must agree on the variable", 
> to use a less coercive, but more compromising law : "only the variable 
> common in all the branches of the or-pattern are bound in the match 
> branch".

This seems like a good rule.  I think it should be refined a little, 
though.  The refinement is: "any variables which occur free in the 
expression must be bound in either all or no branches of the pattern". 
For example, this should be an error:

   let z = 3

   let f = function
     | A x with z = 10
     | B x -> x + z

Without the refinement `f (A 5)' evaluates to 8, which is pretty 
confusing (even with an unused variable warning).

Jeremy.