You might be interested in: https://github.com/janestreet/ppx_variants_conv Example: $ utop utop # #require "ppx_deriving";; utop # #require "ppx_variants_conv";; utop # #require "variantslib";; type t = A of int | C of int * int [@@deriving variants];; type t = A of int | C of int * int val c : int -> int -> t = val a : int -> t = module Variants : sig val c : (int -> int -> t) Variantslib.Variant.t val a : (int -> t) Variantslib.Variant.t val fold : init:'a -> a:('a -> (int -> t) Variantslib.Variant.t -> 'b) -> c:('b -> (int -> int -> t) Variantslib.Variant.t -> 'c) -> 'c val iter : a:((int -> t) Variantslib.Variant.t -> 'a) -> c:((int -> int -> t) Variantslib.Variant.t -> 'b) -> 'b val map : t -> a:((int -> t) Variantslib.Variant.t -> int -> 'a) -> c:((int -> int -> t) Variantslib.Variant.t -> int -> int -> 'a) -> 'a val descriptions : (string * int) list end (I'm not quite sure why you have to do three #require statements manually. Related to this .) > Does everybody use camlp4/p5/ppx to customize the syntax to his liking Note that the community is moving to ppx based syntax extensions, and away from camlp4/5. > 200k of code Where do you see that much code? I only see 6000 lines of code. On Fri, Nov 6, 2015 at 8:09 AM, Soegtrop, Michael < michael.soegtrop@intel.com> wrote: > Dear Gabriel, > > > > thanks for the link, an interesting idea and discussion! And I see that > maybe I should come over to Paris to participate ;-) I would agree with > Alain Frisch’s final comment that whenever a pattern synonym is used in the > RHS, there should be an explicit binder. This would either solve the > “trouble” case or make the similarity to (x, x) obvious. > > > > Best regards, > > > > Michael > > > > *From:* caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] *On > Behalf Of *Gabriel Scherer > *Sent:* Friday, November 06, 2015 1:34 PM > *To:* Soegtrop, Michael > *Cc:* Francois Berenger; caml-list@inria.fr > *Subject:* Re: [Caml-list] Newbie comment on constructor syntax > > > > The use of camlp{4,5} to change OCaml syntax has always had extremely low > adoption, with some very specific exceptions (notably the lwt-support > syntax of the Ocsigen project). I suspect that this is due to the fact that > integrating a new syntax extension to your project has historically caused > more build-system and deployment trouble than people were willing to > tolerate. > > ppx extensions are not designed to allow extending the OCaml syntax, and > in particular I think they are not a good fit for what you are looking for. > It is a large part of their appeal: by being less flexible, they are > simpler and more robust. > > I personally believe that currified constructor syntax would be a better > choice, and that using non-currified constructors is a historical mistake > of SML/Caml. But I am also not convinced that efforts to change it today > are worth the trouble, and prefer to concentrate on improving other parts > of the OCaml ecosystem. > > Another thing that was touched by your comments is the usefulness of > user-defined patterns (pattern synonyms). I have conflicted opinions on the > question of whether adding pattern synonyms would be a good thing, but > described one aspect of a proposal that I like (but also highlights that > the feature can be a source of implementation complexity) in > http://gallium.inria.fr/blog/pattern-synonyms-as-expressions/ > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >