[wg-camlp4] On domain-specific foreign syntaxes

[Alain Frisch]

On 01/31/2013 01:44 PM, Gabriel Scherer wrote:
> 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.

There are two very different topic here: syntax and type-checking.

Clever type-checking of the DSL can be done either with combinators, and 
when this is not possible, it makes sense to have some "pre-processors" 
doing clever stuff like adding type annotations.  When we write:

  (:json { streetAddress: "21 2snd Street" })

or even:

  (:json M["streetAdress", S "21 2snd Street"])

this can be expanded to something more clever than just untyped 
constructors.  But there is no reason to force using the concrete syntax 
of the foreign language (which is not really true, because you want to 
allow anti-quotations which are not part of that syntax).  The syntax of 
OCaml is rich enough that a lot of other languages can be encoded in it. 
  The downside is that we need to make it clear syntactically that a 
fragment will be interpreted in a special way.  The upside is that no 
"parsing technology" is involved, which simplifies the design (choice of 
a syntax for anti-quotations), the implementation (writing a parser and 
calling back the OCaml parser on anti-quotations, with careful tracking 
of locations) and the user experience (support from editors, learning 
details of a concrete syntax [you might want to write JSON producers on 
an abstract level, and benefit from clever type-checking, but without 
knowing exactly how strings have to be escaped in concrete JSON]).

> 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.

When non-programmers have to write some HTML code, this code rarely ends 
up in OCaml source code.  Usually, it stays in its own HTML file, which 
is then processed (statically or dynamically) by the (OCaml) code.

When fragments of JSON/XML/etc are created programatically, this is 
often done "piece by piece", with very small fragments involving a high 
density of anti-quotations.  The benefits of using the foreign syntax 
here are not clear to me.


> 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.

I understand the theoretical argument, but I don't think it would apply 
in practice to many OCaml projects.


Alain