[wg-camlp4] On domain-specific foreign syntaxes

[Philippe Veber]

Not much to add to this, I just wanted to emphasize that the point Gabriel
makes is especially relevant in web programming or database interaction,
because in those area ocaml is not often the first option that comes to
mind. So being able to quote json, sql, html etc in an ocaml source without
unplugging the type checker is real feature. Of course, there are cases
when you build those "foreign" values programmatically, in that case I
concur you're better off without the syntax extension (maybe not always, if
the guest language has some real nice support than cannot be rendered
concisely with ocaml), but there are many times when the antiquotation part
is really small compared to the "constant" fragments. In that case, it may
be desirable to have non-ocaml-programmers work directly on the ml source.

2013/1/31 Gabriel Scherer <gabriel.scherer at gmail.com>

> > From all the uses of Camlp4 I've seen listed since the beginning of this
> > discussion, I can imagine using at some point almost each of them, except
> > those which are basically "just" about quoting fragments of external
> > languages in their native syntax.  I just don't see the real benefits.
> >
> > It would be useful to get feedback from users: do people actually use
> > pa_tyxml, pa_json, etc, and do they consider this is really better than
> > proposed alternatives?
> >
> >
> > Alain
>
> The point of quoting foreign languages is to translate them into a
> form that exercize the OCaml type-checker to produce rich typing
> information. With (parse_json "...") you have no static typing
> information on the parsed value, while with a quotation you can expect
> to get, say, a (< streetAdress : string > Json.t) expression.
> Supporting antiquotations there allows you to write those foreign
> values in a composable way, eg. using <:json< { streetAddress: $addr$
> } >> with (addr : string Json.t).
>
> This is essentially a nice concrete syntax on top of the typed
> combinators (point 1. in your message quoted below); indeed, good
> extensions should embed as few domain knowledge as possible and defer
> that to the pure-ocaml library providing the combinators. That is not
> always possible, however, when you want to express rich binding
> structures in a typed way (for example the support of GROUP BY in a
> finely-typed way in Macaque relies on clever Camlp4 expansion
> strategies.
>
> Furthermore, the bare approach of using combinators directly is not
> always desirable in situations where you want the code to be used by
> non-domain-experts. "Templates" in web programming are an entire
> cottage industry made of preprocessing HTML-looking quasiquotations,
> to help the role separation between designers and programmers. More
> generally, if there is a widely accepted domain-specific notation,
> your domain-specific library should have a way to support it (so that
> you can, for example, call over SQL tuning experts to comment on the
> performance optimization of the database queries embedded in your
> OCaml code).
>
> This is maybe less visible for non-programmable data description
> languages such as JSON, but I suspect this still holds. For example,
> if you distribute a protocol library built on top of JSON and bridging
> over many programming languages, you want the same maintainer to be
> able to quickly reflect changes to the protocol schema over all
> implements. This is vastly easier if they respect the domain-specific
> syntax instead of each having an embedding following the concrete
> syntax of the corresponding language.
>
> On Thu, Jan 31, 2013 at 1:28 PM, Alain Frisch <alain at frisch.fr> wrote:
> > On 01/31/2013 12:48 PM, Leo White wrote:
> >>>
> >>> >> and << are really not keywords of OCaml, and I wouldn't be
> >>> surprised they are actually used as operators.  I prefer breaking
> >>> compatibility with camlp4 than with OCaml.
> >>
> >>
> >> Thinking about it "<:" is not entirely unproblematic. Since "[<" is a
> >> single token, [<:foo< .. >>] would be awkward for the lexer.
> >>
> >> Even if we abandon the camlp4 syntax for quotations
> >
> >
> > Hurrah :-)
> >
> >
> >> , I still think that
> >> {:lid {x{ string }x}} is too heavy and inflexible for traditional
> >> quotations. For example, a JSON quotation would look like:
> >>
> >> {:json {<{ {"streetAddress": "21 2nd Street"} }>}}
> >
> >
> > I would write this:
> >
> > (:json {{ {"streetAddress": "21 2nd Street"} }})
> >
> > And if we keep the "end marker" in the AST, this could be:
> >
> > {json{ {"streetAddress": "21 2nd Street"} }json}
> >
> >
> > But maybe we should take a step back, and really ask ourselves why we
> should
> > use concrete JSON syntax here.  Other possibilities:
> >
> >
> > 1. Write the JSON AST directly as regular OCaml code:
> >
> >  Json.(M["streetAdress", S "21 2snd Street"])
> >
> >  (assuming module Json export constructors M and S.)
> >
> > 2. Use "parsed" OCaml syntax, with some -ppx filter mapping it to JSON
> AST:
> >
> >  (:json { streetAddress: "21 2snd Street" })
> >
> > (which would expand to the version above)
> >
> >
> > 3. Use a JSON parser (if we don't need "anti-quotations"):
> >
> >   parse_json "{\"streetAddress\": \"21 2nd Street\"}"
> >
> >   or:
> >
> >   parse_json {{ {"streetAddress: "21 2nd Street"} }}
> >
> >
> > From all the uses of Camlp4 I've seen listed since the beginning of this
> > discussion, I can imagine using at some point almost each of them, except
> > those which are basically "just" about quoting fragments of external
> > languages in their native syntax.  I just don't see the real benefits.
> >
> > It would be useful to get feedback from users: do people actually use
> > pa_tyxml, pa_json, etc, and do they consider this is really better than
> > proposed alternatives?
> >
> >
> > Alain
> >
> > _______________________________________________
> > wg-camlp4 mailing list
> > wg-camlp4 at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/wg-camlp4
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130131/6effd0e9/attachment.html>