[wg-camlp4] On domain-specific foreign syntaxes
Gabriel Scherer
gabriel.scherer at gmail.com
Thu Jan 31 12:44:59 GMT 2013
> 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
More information about the wg-camlp4
mailing list