On Mon, Jul 26, 2010 at 5:13 PM, Nicolas Pouillard
<nicolas.pouillard@gmail.com> wrote:
> On Mon, 26 Jul 2010 16:41:46 +0200, Raphael Proust <raphlalou@gmail.com> wrote:
> > Hi all,
> Hi,
>
> > [...]
> >
> > (* Pre-parsed code: *)
> > let start = <:on< f $y$ >> in
> > let html_node =
> >  span ~a:[onclick start] "some text" (* a is used for (html) attributes *)
> >
> > (* Server side post-parsed code: *)
> > let start _arg1 =
> >  "call_closure(some_unique_name," ^ mymarshall _arg1 ")"
> > in
> > let html_node = span ~a:[onclick (start y)] "some text"
> >
> > (* Client side post-parsed code: *)
> > let _ = register_closure some_unique_name (fun _arg1 -> f _arg1)
> >
> >
> > 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.
> >
> > [...]
>
> If the <:on<...>> contents is valid OCaml syntax I would suggest you to not go
> in the quotations direction. You will avoid a ton of syntactic issues.
>
> What I suggest you is to directly use camlp4 filters, for instance by changing
> the meaning of some constructor application and labels for antiquotations:
>
> (* Pre-parsed code: *)
> let start = On (f ~y) in
> let html_node =
>  span ~a:[onclick start] "some text" (* a is used for (html) attributes *)

I'd rather not use a constructor because it imposes a strong limitation on the
user (it basically reserves a keyword) whereas the <:on< ... >> solution does
not (<:smthg< ... >> is already "reserved").

And labeling antiquotations is far from ideal since it prevents complex
expressions from being inlined. You basically need to write:
  let y = h a in
  let z = g x z in
  On (f ~y ~z)
instead of:
  <:on< f $h a$ $g x z$ >>

What I basically need is to get an AST with antiquotations and quotations being
special nodes. How is this achievable w/o reimplementing a whole grammar?

The alternative solution is to use raw strings, to find antiquotation marks, to
split the string and to reinject it in the different files. Is there a way to
keep precise _loc information this way?




--
_______
Raphael