Re: [Caml-list] Newbie comment on constructor syntax

[Ashish Agarwal <agarwal1975@gmail.com>]

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

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 = <fun>
val a : int -> t = <fun>

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 <https://github.com/janestreet/ppx_sexp_conv/issues/1>.)


> 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
>

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