From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C6364BC32 for ; Tue, 8 Mar 2005 21:46:11 +0100 (CET) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j28KkBgX019095 for ; Tue, 8 Mar 2005 21:46:11 +0100 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id DD17AC5CE15; Tue, 8 Mar 2005 15:46:09 -0500 (EST) X-Sasl-enc: WoFxxlsRUKDa0cBCAh85Hg 1110314769 Received: from [172.16.112.115] (burnham.ljcrf.edu [192.231.106.2]) by frontend3.messagingengine.com (Postfix) with ESMTP id 1E77628689; Tue, 8 Mar 2005 15:46:09 -0500 (EST) Date: Tue, 8 Mar 2005 12:46:02 -0800 (PST) From: Martin Jambon X-X-Sender: martin@localhost To: Andreas Rossberg Cc: caml-list@yquem.inria.fr Subject: AST traversal functions (was: SML->OCaml) In-Reply-To: <005701c523be$d1997260$14b2a8c0@wiko> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 422E0F13.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ast:01 ocaml:01 rossberg:01 constructors:01 implicitly:01 sml:01 sig:01 val:01 struct:01 datatype:01 violate:01 datatype:01 sml:01 reuse:01 syntax:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Tue, 8 Mar 2005, Andreas Rossberg wrote: > In fact, it would be much more complicated. First, identifier status is > scoped. Constructors are frequently defined locally. In particular, this may > happen implicitly through the use of "open". To derive the required > information you hence needed to perform a complete binding analysis, > including modules and signatures. > > Then, SML actually allows constructor status to be withdrawn from an > identifier. For example, the following program is valid: > > signature S = sig type t val x : t end > structure A : S = struct datatype t = x end > > There are few programs that make use of this possibility, but I expect them > to coincide with those that violate the usual case conventions in the first > place. An SML-to-OCaml translator had to go to quite some length to > translate such programs. > > In summary, to deal with constructor status correctly (not to mention stuff > like datatype replication, local, records, user-defined fixity, etc.) you > basically need half an SML frontend. It seems out of scope for a Camlp4 hack > to be more than a simple approximation. Yes, but I believe there should be a convenient way at least to reuse the syntax tree produced by the current converter, and convert the incorrect uppercase/lowercase identifiers. It just requires a good root-to-leaves substitution function which does not ask us to match explicitely every kind of node of a given type (which is extremely repetitive and error-prone, even with quotations). I already thought of doing this (actually automatically deriving such a higher-order function from the type definition of the AST: Pcaml.expr and friends). Example: let X = 1 in fun x -> X We should be able to specify that let $patt$ = $e1$ in $e2$ adds the binding to the current environment for converting expr. And by default, everything is just "traversed". For instance, the case $e1$ + $e2$ which is itself an expression should not be explicitely unconstructed/substituted/reconstructed, that would be done automatically. This would let us focus only on the specific cases such as "open", "let ... in", "fun ...", "let ..." (or "val ..."), simple identifiers and module-related issues. Martin