From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 81F4CBC69 for ; Wed, 7 Mar 2007 12:15:35 +0100 (CET) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l27BFYTD025423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Mar 2007 12:15:35 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from first (p548EF4CE.dip.t-dialin.net [84.142.244.206]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l27BFXsx005202 for ; Wed, 7 Mar 2007 12:15:34 +0100 Received: by first (Postfix, from userid 501) id ED9C63820FD; Wed, 7 Mar 2007 12:15:29 +0100 (CET) Date: Wed, 7 Mar 2007 12:15:29 +0100 From: Oliver Bandel To: OCaml Subject: Re: [Caml-list] Patterns that evaluate Message-ID: <20070307111529.GA444@first.in-berlin.de> References: <45D23608.4030104@mcmaster.ca> <45D37AD0.3090002@mcmaster.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 45EE9ED6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 compiler:01 fpls:01 fpls:01 wrote:01 oliver:01 oliver:01 caml-list:01 match:02 binding:02 explicit:03 pattern:04 pattern:04 thu:05 On Thu, Feb 15, 2007 at 12:43:22PM -0800, Nathaniel Gray wrote: [...] > One potential "solution" to this problem for new users would be a > compiler warning when you shadow an existing variable in an explicit > pattern match. [...] Shadowing an existing "variable": isn't this the normal way how FPLs "do it"? It's: the inner (local) environment overwrites the outer environments and that's, how FPLs are doing it. A new binding to a name. Should all re-bindings be worth a warning? if not: which should create a warning, which not? Is this necessary in pattern matches only? Ciao, Oliver