From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr 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 EB6FFBB83 for ; Fri, 21 Jul 2006 02:11:23 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6L0BNKc002727 for ; Fri, 21 Jul 2006 02:11:23 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA11363 for ; Fri, 21 Jul 2006 02:11:22 +0200 (MET DST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6L0BIgd002718; Fri, 21 Jul 2006 02:11:22 +0200 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9AB87D9112B; Thu, 20 Jul 2006 20:11:16 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Thu, 20 Jul 2006 20:11:19 -0400 X-Sasl-enc: GsmaU1ygcWMbEHsZjSJJGffrcj05DkeBVRIteOVch/Z+ 1153440679 Received: from [172.16.112.115] (burnham.ljcrf.edu [192.231.106.2]) by mail.messagingengine.com (Postfix) with ESMTP id 1E25C170; Thu, 20 Jul 2006 20:11:17 -0400 (EDT) Date: Thu, 20 Jul 2006 17:11:11 -0700 (PDT) From: Martin Jambon X-X-Sender: martin@localhost To: Alain Frisch Cc: Martin Jambon , =?ISO-8859-1?Q?B=FCnzli_Daniel?= , Eric Breck , caml-list@inria.fr Subject: Re: Camlp4 mysteries (was Re: On language extensions (was Re: [Caml-list] global record)) In-Reply-To: <44C013EC.2080201@inria.fr> Message-ID: References: <51E3580C-02A1-4344-A5AA-862B580015F1@cs.cornell.edu> <60FD7628-7F4E-4765-88AD-B3AB7DA987D0@epfl.ch> <44C013EC.2080201@inria.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-j-chkmail-Score: MSGID : 44C01BA6.000 on concorde : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 44C01BAB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44C01BA6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; camlp:01 frisch:01 syntax:01 syntax:01 syntactical:01 camlp:01 makefiles:01 ocaml:01 bindings:01 redefinition:01 1977:98 wrote:01 wrote:01 caml-list:01 usable:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=disabled version=3.0.3 On Fri, 21 Jul 2006, Alain Frisch wrote: > Martin Jambon wrote: >> Otherwise it's possible to define well-disciplined syntax extensions. >> For example, if each new syntax construct (new rule) is forced to start >> with a unique, registered keyword and end with "end", then different >> syntax extensions that follow this rule should play well together. > > Except that any new keyword can potentially break existing code. You'd > need some other syntactical convention. Sure, but for future code which uses future syntax extensions, it will be OK. For the current extensions, it is possible to offer alternatives (via a -std option or something like that). If I understand correctly, we will have to adapt quite a few things for our syntax extensions to support the new Camlp4, so while we are at it, adding an alternate standardized syntax won't be a problem if it doesn't require too much thinking. (In addition to that, like Skaller suggested, something like "open syntax Mysyntax" would make syntax extensions available like library modules, which simplifies makefiles and doesn't force every module to use them. But that's about integrating Camlp4 tightly in the OCaml language, which is another story) >> It would be really nice to have official guidelines on how to develop >> clean syntax extensions, if not automatic enforcement. > > Do you have concrete examples of extensions that don't play well together? Yes, mine :-) In micmatch I delete and redefine the constructs with bindings: let, let in, match, try, function. The resulting syntax gives the illusion of a nice integration, but this is a redefinition of the existing constructs, so if another extension does the same, only the one which is loaded last will be usable. In practice I haven't had any problem like that, but it's a possibility. So this is why someone should decide of a standard, and we will follow it. Martin -- Martin Jambon, PhD http://martin.jambon.free.fr