caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: "François Pottier" <francois.pottier@inria.fr>
Cc: Peter Zotov <whitequark@whitequark.org>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] ppx_deriving question: deferring code generation?
Date: Wed, 4 Jan 2017 08:49:11 -0500	[thread overview]
Message-ID: <CAPFanBFfXpF-G9DK7io8c0hR2DT2rA=DwK8F0pC5Ffw7HvHFmg@mail.gmail.com> (raw)
In-Reply-To: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr>

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4301 bytes --]

  reply	other threads:[~2017-01-04 13:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 13:08 François Pottier
2017-01-04 13:49 ` Gabriel Scherer [this message]
2017-01-04 15:37   ` François Pottier
2017-01-04 13:53 ` Christoph Höger
2017-01-04 15:58   ` François Pottier
2017-01-04 15:20 ` Alain Frisch
2017-01-04 16:04   ` François Pottier
2017-01-06 22:58 ` whitequark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPFanBFfXpF-G9DK7io8c0hR2DT2rA=DwK8F0pC5Ffw7HvHFmg@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=francois.pottier@inria.fr \
    --cc=whitequark@whitequark.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).