[wg-camlp4] Extension developers: we need you!

[Gabriel Scherer]

A small remark requesting no immediate action, but maybe suggestions
of things to work on (not necessarily for Alain) in the future.

I remarked in a recent extension example by Alain (
https://github.com/ocaml/ocaml/commit/f7fee51ae33e357714b03f7f9b025a1a48182549
) that a non-neglectible portion of the code logic is dedicated to
"option processing". Alain uses optional attributes to tune the code
generation of his -ppx extension, and he has to process them very much
like command-line options in an application: get the value of them,
turn that into program-specific logic, handle options that don't make
sense when provided both at the same time, etc.

>From his commit:

+(*
[...]
+  We recognize some special attributes on record fields (or their associated
+  type) and on constructor argument types:
+
+  - [@label id]: specify a label for the parameter of the builder function
+    (for records, it is set automatically from the label name
+    but it can be overridden).
+
+  - [@opt]: the parameter is optional (this assume that the field/argument
+    has an option type).
+
+  - [@default expr]: the parameter is optional, with a default value
+    (cannot be used with [@opt]).
+*)

[...]

+  let param named name loc attrs =
+    let default = find_attr "default" attrs in
+    let opt = has_attr "opt" attrs in
+    let label =
+      match find_attr "label" attrs with
+      | None -> if named then name else ""
+      | Some e ->
+          match get_lid e with
+          | Some s -> s
+          | None -> fatal e.pexp_loc "'label' attribute must be a
string literal"
+    in
+    let label =
+      if default <> None || opt then
+        if label = "" then fatal loc "Optional arguments must be
named" else "?" ^ label
+      else label
+    in
+    if default <> None && opt then fatal loc "Cannot have both 'opt'
and 'default' attributes";
+    lam ~label ?default (pvar name), (name, evar name)

I expect that we will see similarly-looking pieces of code in most
extensions using attributes to tune behavior, and that would be a good
candidate for a proper library abstraction allowing a more declarative
style of programming.

What are the right abstraction to describe such optional attributes?
Can we reuse libraries dedicated to command-line processing, or only
their ideas?

As far as I know, the most advanced work in this direction in the
OCaml community is Daniel Bünzli's Cmdliner library:
  http://erratique.ch/software/cmdliner/doc/Cmdliner
Can we reuse Cmdliner for -ppx extensions?

(On the paper that is work that would also apply to Camlp4/Fan
extensions, but in practice I haven't encountered this kind of
optional parametrizations in mainstream Camlp4 extension, and I
suspect Alain's attribute model is a necessary and sufficient feature
for them to gain wider use.)

Consider this email as a TODO list item: at some point, we would need
someone to invest time to think about that, and produce a reusable
library for this aspect of extension development.

PS: Alain, type-driven code generation is a terrible name to qualify
this particular extension, as I was expecting code generation driven
by type information in a typedtree. This is code generated from
(syntactic) type *definitions*. If "type-definition-driven code
generation" is too long, maybe "deriving-style extension" would be
reasonable.

On Wed, Apr 3, 2013 at 7:16 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> Now is a good time to start collecting more concrete feedback from extension
> developers on the current proposal (ppx + extension_points). Are there
> people on this list interested in porting their existing extensions (or
> other tools which can benefit from attributes)?   This will be greatly
> helpful if the current design can be validated by real extension developers.
> Porting real extensions will also help to isolate a good set of
> "convenience" functions to build or deconstruct AST fragments in a light
> way.
>
> (Disclaimer: there will still be some more cleanups to the Parsetree
> definition and helper modules (Ast_mapper, Ast_helper), so the code written
> now will need to be adjusted for the final version, but I expect those
> changes to be quite easy.)
>
>
> -- Alain
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4