The semantics you propose is inherently stateful: delays accumulates some state and [@@visitors]'s meaning (nitpick: I think it should be a floating attribute, [@@@visitors]) depends on the current state. You could design a similar facility using names for references instead of implicit state:

  type foo =
    Bar | Baz

  let x : foo option ref =
    ref None

  [@@@deriving.for foo (visitors)]

(If we had access to the type-checking environment, [@@deriving.for p] could be valid for any qualified identifier p that points to a transparent definition in the current environment. Given the current ppx pipeline, I suppose that would have to be restricted to being in the syntactic scope of an actual declaration.)

Hongbo Zhang introduced a similar "deriving from a distance" feature in his preprocessor Fan, for the reason you give, and also to allow deriving boilerplate code of datatypes defined in third-party libraries without having to modify them directly.


On Wed, Jan 4, 2017 at 8:08 AM, François Pottier <francois.pottier@inria.fr> wrote:

Hello all,

I am currently in the process of writing a ppx_deriving plugin, called
"visitors". Overall, this has been a pleasant experience; a few hundred lines
of code have been sufficient to obtain nontrivial results.

In normal use, the user writes something like this:

  type foo =
    Bar | Baz
    [@@deriving visitors]

and some generated code is inserted just after the definition of the type foo.

However, I have reached a situation where the generated code cannot be placed
just after the type definition. That is, I need to allow user-written code to
appear after the type definition and before the generated code.

For instance, this user-written code could be a declaration of a global
variable "x", whose type is "foo ref", and which the generated code uses. The
declaration of "x" must appear after the definition of the type "foo", because
the type of "x" mentions "foo". And the declaration of "x" must appear before
the generated code, because the generated code (intentionally) refers to "x".

I am imagining that perhaps the user could write something like this:

  type foo =
    Bar | Baz
    [@@deriving visitors { delayed = true }

  let x : foo option ref =
    ref None

  [@@visitors]

The effect of the flag { delayed = true } would be to store the generated code
somewhere in memory (instead of emitting right away), and the effect of the
floating attribute [@@visitors] would be to fetch that code from memory and
emit it.

To me, this seems somewhat ugly, but workable. Does ppx_deriving offer a
better approach? Does anyone have a better suggestion? Comments are
appreciated.

Best regards,

--
François Pottier
francois.pottier@inria.fr
http://gallium.inria.fr/~fpottier/

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs