Re: [Caml-list] ppx_deriving question: deferring code generation?

[Alain Frisch <alain.frisch@lexifi.com>]

Hello François,

I don't know if this would cover all similar cases, and perhaps it is a 
bit verbose, but what about something like:

     include(struct
      type foo = Bar | Baz

      let x = ...
     end [@deriving visitors])

i.e. use an attribute on the module expression (and interpret it by 
appending more declarations to the structure).


Cheers,

Alain

On 04/01/2017 14:08, François Pottier 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/
>