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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id A6424BBC1 for ; Mon, 28 Apr 2008 02:01:02 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBABOxFEjAXQIniGdsb2JhbACRWgEBAQ8glww X-IronPort-AV: E=Sophos;i="4.25,713,1199660400"; d="scan'208";a="12010474" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Apr 2008 02:00:45 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m3S00idx016543 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 28 Apr 2008 02:00:44 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQCAKuwFEhCbwQcgWdsb2JhbACRWgEBECADlwk X-IronPort-AV: E=Sophos;i="4.25,713,1199660400"; d="scan'208";a="25577120" Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Apr 2008 02:00:43 +0200 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8F11D10520E; Sun, 27 Apr 2008 20:00:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 27 Apr 2008 20:00:37 -0400 X-Sasl-enc: 8M2aySmmj0F5+/Ld/L3RAz0FA4SOGVx2aogvJK5fgNxE 1209340836 Received: from [192.168.1.10] (ALyon-157-1-7-80.w90-28.abo.wanadoo.fr [90.28.182.80]) by mail.messagingengine.com (Postfix) with ESMTPSA id A1245639; Sun, 27 Apr 2008 20:00:36 -0400 (EDT) Date: Mon, 28 Apr 2008 01:58:54 +0200 (CEST) From: Martin Jambon X-X-Sender: martin@martin.ec.wink.com To: Richard Jones Cc: caml-list@inria.fr Subject: Re: [Caml-list] Cross-module data in camlp4 In-Reply-To: <20080427225207.GA24916@annexia.org> Message-ID: References: <20080427225207.GA24916@annexia.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 481513AC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ens-lyon:01 camlp:01 syntax:01 syntax:01 camlp:01 hashtbl:01 hash:01 substituted:01 compilation:01 compilation:01 regexps:01 lib:01 regexps:01 lib:01 mli:01 On Sun, 27 Apr 2008, Richard Jones wrote: > I'm trying to add named patterns to my bitmatch syntax extension. The > idea would be you could write (exact syntax isn't nailed down yet): > > let p = BITMATCH { a : 4; b : 4 } ;; > > bitmatch bs with > | { p } -> (a, b) > > let f a b = BITSTRING p > > This is analogous to micmatch's Named regular expressions feature: > > http://martin.jambon.free.fr/micmatch-manual.html#htoc5 > eg: > RE phone = digit{3} '-' digit{4} > > Reading the code to micmatch, these are implemented by saving the > camlp4 AST into a Hashtbl, so the example above would create a hash > entry ("phone" -> abstract syntax tree of (digit{3} '-' digit{4})). > At the point of use of the named RE, the AST is substituted. Yes. It's a global table that ignores everything about module boundaries. > Of course micmatch's scheme only works if the named RE appears in the > same compilation unit as the substitution. There is no way that I can > see to save these named expressions across compilation units. In > other words this is not allowed: > > --- my_regexps_lib.ml ----- > RE phone = digit{3} '-' digit{4} > > --- my_regexps_lib.mli ----- > val phone : Micmatch.regexp > > --- another file ----- > open My_regexps_lib > (* ... and use 'phone' *) > > I think this limits the usefulness of named expressions, but at the > same time I don't know how one would go about implementing > cross-module named expressions. Is it even possible? Presumably if > it could be done at all, we'd have to save the camlp4 AST > representation into the output file (*.cmo). It would be easy enough > to marshal the AST into a string at the point of definition. I don't > quite see how it can be accessed & unmarshalled at the point of use > however. > > Any insights here gratefully accepted! I had some ideas on the subject: http://caml.inria.fr/pub/ml-archives/caml-list/2007/01/6f2e2f9db39543e92806742ddc10fa5f.en.html Nothing clear comes out of this... Martin -- http://wink.com/profile/mjambon http://mjambon.com