Very nice.

I've never used any of the deriving extensions before, but I have an
aesthetic suggestions. Would it perhaps make sense to generate a module per
derived type? For example a type t would generate a module T_ (the
underscore or any other suffix would reduce mixups with pre-existing
modules). You could then use code such as

'if T_.(a = b && b = c) ...'

or  'T_.show x ...'

which allows you to keep the infix notation for = which is important IMO.

You could even generate T_ as having internal Eq, Ord, and Show modules (as
requested by the user), which would be included in the T_ module. This
would allow you to easily pass them as first class modules to functions
accepting Eq, Ord or Show signatures.

Yotam



On Wed, Jul 23, 2014 at 5:55 AM, Peter Zotov <whitequark@whitequark.org>
wrote:

> Hello,
>
> I'm glad to announce an initial release of ppx_deriving,
> a modular syntax extension for type-driven code generation.
> It will be shortly available in OPAM.
>
> I will introduce ppx_deriving with an example:
>
> # #require "ppx_deriving";;
> # type file = {
>   kind : [ `File | `Dir ];
>   name : string;
>   perm : int [@printer fun fmt -> Format.fprintf fmt "0o%03o"];
> } [@@deriving Show, Eq];;
> type file = { kind : [ `Dir | `File ]; name : bytes; perm : int; }
> val pp_file : Format.formatter -> file -> unit = <fun>
> val show_file : file -> bytes = <fun>
> val equal_file : file -> file -> bool = <fun>
> # print_endline (show_file { kind = `Dir; name = "bin"; perm = 0o755 });;
> { kind = `Dir; name = "bin"; perm = 0o755 }
> - : unit = ()
>
> A more thorough description is available in README[1].
>
> While I intend this release to primarily serve as a preview for
> the community and a means to gather feedback, it is fully usable
> and documented. Some of the planned features (marked "TBD" in README)
> are not yet implemented.
>
> I hope that ppx_deriving can serve as a future replacement to both
> ocsigen's deriving and JaneStreet's type_conv. If you are responsible
> for these libraries, please get in touch. The OCaml ecosystem would
> benefit from a single type-driven code generation mechanism.
>
> I welcome any comments.
>
>   [1]: https://github.com/whitequark/ppx_deriving/
>
> --
> Peter Zotov
> sip:whitequark@sipnet.ru
>
> --
> 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
>