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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id DEB88BC69 for ; Tue, 16 Oct 2007 19:44:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAOVFEfAXQInh2dsb2JhbACOTgEBAQgKKYEn X-IronPort-AV: E=Sophos;i="4.21,284,1188770400"; d="scan'208";a="18100738" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Oct 2007 19:44:29 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l9GHiTDu021538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 16 Oct 2007 19:44:29 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMeUFEeBrw8Eh2dsb2JhbACOTgEBAQgKKYEn X-IronPort-AV: E=Sophos;i="4.21,284,1188770400"; d="scan'208";a="3065306" Received: from ext.lri.fr ([129.175.15.4]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Oct 2007 19:44:28 +0200 Received: from localhost (localhost [127.0.0.1]) by ext.lri.fr (Postfix) with ESMTP id EF398A467F; Tue, 16 Oct 2007 19:44:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lri.fr Received: from ext.lri.fr ([127.0.0.1]) by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS6i6Ra8lqCC; Tue, 16 Oct 2007 19:44:28 +0200 (CEST) Received: from [192.168.0.10] (mry91-1-82-229-156-20.fbx.proxad.net [82.229.156.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ext.lri.fr (Postfix) with ESMTP id AB408A4650; Tue, 16 Oct 2007 19:44:28 +0200 (CEST) Message-ID: <4714F87B.8040807@lri.fr> Date: Tue, 16 Oct 2007 19:44:27 +0200 From: Jean-Christophe User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: David Teller Cc: OCaml Subject: Re: [Caml-list] Pattern-matching destructors ? References: <1192548046.6061.18.camel@Blefuscu> In-Reply-To: <1192548046.6061.18.camel@Blefuscu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 4714F87D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; filliatre:01 lri:01 node:01 nodes:01 recursive:01 node:01 recursive:01 javascript:98 rec:01 rec:01 caml-list:01 purely:02 ast:02 ast:02 inferred:02 David Teller a écrit : > > I'm currently working on static analysis of JavaScript 2. For this, I > need to keep lots of informations in each node of my AST, including > things such as line/column (for better error messages), unique > identifier (for storing inferred information), etc. As things progress, > I fear that the number of such informations is growing prohibitive and > very much getting into the way of pattern-matching. I don't see why a lot of information in AST nodes is getting into the way of pattern-matching. When decorating ASTs, you basically replace a type definition such as type t = | A | B of b | C of string * t * t | D of t list by two mutual recursive types type t = { node : t_node; ... a lot of information here, in other fields ... } and t_node = | A | B of b | C of string * t * t | D of t list As you can see, this is a purely local modification: three lines were inserted (between "type t" and "="). As for pattern-matching, this is exactly the same: the modification is only local. Indeed, your recursive function over type t, which was looking like let rec f = function | A -> ... | B b > ... | C (s, t1, t2) -> ... (f t1) ... (f t2) ... | D l -> ... is turned into let rec f t = f_node t.node and f_node = function | A -> ... | B b > ... | C (s, t1, t2) -> ... (f t1) ... (f t2) ... | D l -> ... Again we only inserted new lines between "let rec f" and "= function". I agree that nested pattern-matching is slightly different, though. But as already said by somebody else, you can match against field node only, which looks like | C (s, {node=A}, {node=D l}) -> ... I don't see that as really intrusive. Hope this helps, -- Jean-Christophe