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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B7A6BBBAF for ; Mon, 26 Jul 2010 22:53:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYCAE6STUxKfVK0kGdsb2JhbACDFJxHCBUBAQEBCQkMBxEDH7IGO4IQhhQuiFQBAQMFgSGDHXMEiGQ X-IronPort-AV: E=Sophos;i="4.55,263,1278280800"; d="scan'208";a="66961821" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Jul 2010 22:53:03 +0200 Received: by wyb33 with SMTP id 33so3070967wyb.39 for ; Mon, 26 Jul 2010 13:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fCLvQ3sS5tBUWe64ihe/0HgXP/qwQYien2+D9ercmKA=; b=prQNFnUMNPm2J9bH3UmXIEJOveOkO+y8lHtBO5s8X6EKr/ymTR9KJRQgf0vq0rbUWA qOUpNPtysXAKIwMomTrjLuUPe87vNzR9nOKFBvGvHrqu3tEJh8nA2DL0NUXsURjA7+ZQ 7MJkClwFI1aK7KdChRXQluaCn35VVr+72VDtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yw9Zdle1IukNT8ITHTAtSYYEhoW1r5BaiiLS+wNcf8+ffUspbrY8nf1O3ainL/ZKJz AdLrQhmKgvhpV93Gs8t7131uSPpTiNAidD4DadQsggdA+ZcEh2w/r+RrUsXajPxyGPz7 8jZiEtLgiNwog5QkhM4b9KX4SCfrAUa7UikAw= MIME-Version: 1.0 Received: by 10.227.68.207 with SMTP id w15mr7890389wbi.75.1280177582942; Mon, 26 Jul 2010 13:53:02 -0700 (PDT) Received: by 10.216.182.132 with HTTP; Mon, 26 Jul 2010 13:53:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Jul 2010 22:53:02 +0200 Message-ID: Subject: Re: [Caml-list] [Camlp4] Quotation expander with OCaml syntax From: Raphael Proust To: bluestorm Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8 X-Spam: no; 0.00; camlp:01 expander:01 ocaml:01 syntax:01 syntax:01 non-trivial:01 camlp:01 ocaml:01 expander:01 simulate:01 mutable:01 expr:01 pointers:01 26,:98 26,:98 On Mon, Jul 26, 2010 at 10:08 PM, bluestorm wrote: > On Mon, Jul 26, 2010 at 4:41 PM, Raphael Proust wrote: >> I'm working on a syntax extension as part of an internship in the >> Ocsigen team. The aim of the syntax extension is to split the code of a web >> application in two separate files: one for the client and one for the >> server. A few transformations are to take place in the process. > > Are you sure you need to split the code in two different files ? Could > you not produce only one file, emitting code for both the server and > the client behavior, with two separate entry point (say server_main() > and client_main()) to call from the outside ? That would probably not be that convenient because (a) the server rarely has a main function in these modules (although a let server_main () = () would do), (b) the client needs to be compiled with specific libraries (for DOM manipulation and other Javascript things), (c) the client code has to be compiled with a different build process (because of the Javascript based target environment) > > Pros : > - no need to split files (naming issues, location issues, etc.) The naming issues are not that difficult to manage since the two files are generated together. Location is harder to manage, but dumping the AST should preserves locations (I think). > - easier to ensure consistency between the two sides (for example, if > you want type information to flow from one side to the other); might > be an important factor if you're doing non-trivial things There's another quotation (<:shared< ... >>) that duplicates code amongst the two sides. That takes care of type declarations being shared. It could be good to have this all-in-one file compiled to ensure type checking. We are actually implementing another solution, but I'll keep this one in mind. > > Cons : > - possibly less convenient to use > - client has to load the server code as well > > >> I'm unsure of what is the standard way of doing such a thing in Camlp4. What >> I have in mind is to use the original Ocaml syntax for the quotation expander. >> This would (IIUC) allow me to filter the AST to transform every >> antiquotation found inside the quotation itself. >> I'm not sure this is the ideal way of doing such a thing because of the size >> of the pattern matching in the AST filter. > > It seems to me that you would only handle antiquotations in > expressions (or do you have a "client-server communication" meaning > for antiquotations inside other syntaxic constructs such as types or > patterns ?). Matching some cases (in that case, one) in one of the > syntaxic classes is *very* easy and quite elegant thanks to the `map` > and `fold` classes of Camlp4Ast `foldmap` could also be helpful but it > seems it is not generated by default for Camlp4Ast. If you need it > (and I think you'd need it), you can simulate a mapfold by adding a > mutable state variable to a mapper class. The antiquotations might only occur inside quotations that are either expr (for event handler) or str_item (for shared declarations). The antiquotations have a slightly different meaning in the two cases, but it would be long to explain. I'll look for these functions. Thanks for the pointers. -- _______ Raphael