caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Raphael Proust <raphlalou@gmail.com>
To: bluestorm <bluestorm.dylc@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] [Camlp4] Quotation expander with OCaml syntax
Date: Mon, 26 Jul 2010 22:53:02 +0200	[thread overview]
Message-ID: <AANLkTi=YW098YAVBc9yOKtP0H5h4qZ7HkT=oOXDyiutR@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikv=stwHrYxjUz=6V9XGrnvPEpispyBVbE50ogu@mail.gmail.com>

On Mon, Jul 26, 2010 at 10:08 PM, bluestorm <bluestorm.dylc@gmail.com> wrote:
> On Mon, Jul 26, 2010 at 4:41 PM, Raphael Proust <raphlalou@gmail.com> 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


  reply	other threads:[~2010-07-26 20:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTikuoN4H0Hsx74JwW66J9jmtq+usDxtQPpYfSGbd@mail.gmail.com>
2010-07-26 14:41 ` Raphael Proust
2010-07-26 15:13   ` [Caml-list] " Nicolas Pouillard
2010-07-26 15:41     ` Joel Reymont
2010-07-26 16:05       ` Jake Donham
2010-07-26 15:41     ` Raphael Proust
2010-07-26 16:27       ` Nicolas Pouillard
2010-07-26 16:30       ` Jake Donham
2010-07-27  7:57         ` Raphael Proust
2010-07-26 20:08   ` bluestorm
2010-07-26 20:53     ` Raphael Proust [this message]
2010-07-27 13:22   ` Thomas.Gazagnaire
2010-07-27 14:38     ` Raphael Proust
2010-07-27 14:47     ` Vincent Balat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=YW098YAVBc9yOKtP0H5h4qZ7HkT=oOXDyiutR@mail.gmail.com' \
    --to=raphlalou@gmail.com \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).