From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 16EEB7ED1C for ; Fri, 25 Sep 2015 23:00:47 +0200 (CEST) IronPort-PHdr: 9a23:Hx6b1RTWFKumwt6BuMsZRqUs49psv+yvbD5Q0YIujvd0So/mwa64YBSN2/xhgRfzUJnB7Loc0qyN4/ymBDVLucjJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvip9uOOk4Q2nKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGfayQ6NtRrVdCHEiMnspzMztrxjKCwWVtVUGVWBDjRpJHwXc8RjgXd+lrSv7qudkxSCAPuXpTbEoVC2/5r1oDhjyh3FUZHYC7GjLh5ko3+pgqxW7qkknzg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=whitequark@whitequark.org; spf=Pass smtp.mailfrom=whitequark@whitequark.org; spf=None smtp.helo=postmaster@mail.whitequark.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBABatQVW/31nOrBdg3hpv0GHYxABAQEBAQEBAYEJgh2CRgJTEGlMiCoJqB6kL4pLhlCEFQWNcId8gVCDRId1ghmMKUSMLDgrgUoLAQEBgiw7MwEBiR8BAQE X-IPAS-Result: A0CnBABatQVW/31nOrBdg3hpv0GHYxABAQEBAQEBAYEJgh2CRgJTEGlMiCoJqB6kL4pLhlCEFQWNcId8gVCDRId1ghmMKUSMLDgrgUoLAQEBgiw7MwEBiR8BAQE X-IronPort-AV: E=Sophos;i="5.17,588,1437429600"; d="scan'208";a="179492489" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 25 Sep 2015 23:00:46 +0200 Received: by mail.whitequark.org (Postfix, from userid 33) id C2801138FA5; Fri, 25 Sep 2015 21:00:45 +0000 (UTC) To: caml-list@inria.fr X-PHP-Originating-Script: 1000:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 26 Sep 2015 00:00:45 +0300 From: whitequark Message-ID: <6c322406f51662321d5f320f2e4f4f78@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.1.0 Subject: [Caml-list] [ANN] ppx_deriving 3.0 Hello, I am glad to announce ppx_deriving 3.0. It brings two major changes: hygiene and ppx_type_conv compatibility. It is installable via opam[1]. First, hygiene. Earlier versions of ppx_deriving: 1) assumed that all the modules that the deriver requires are not shadowed with a different signature; 2) included user-specified code such as from [@default] attributes in a way that exposed deriver-internal identifiers to such code. Now, ppx_deriving includes a mechanism for hygienic unquoting[2], as well as a module[3] containing references to most standard library modules under their proper names. This allows it to coexist with e.g. `open Core.Std`. Second, ppx_type_conv compatibility. You probably don't know it yet, but Jane Street has converted all their syntax extensions to ppx, so now there's ppx_type_conv, ppx_sexp_conv, etc. I've coordinated the development of ppx_deriving with Jane Street, so now ppx_deriving and ppx_type_conv use the same syntactic conventions. In fact, they share the [@@deriving] syntax without any effort from the user! Furthermore, I have been looking at the sources of Jane Street's ppx_core, ppx_driver, ppx_type_conv, etc and I find these projects exceptionally well designed; further, they tackle some important problems that ppx_deriving has explicitly left out of scope, such as attribute hygiene. While these libraries have a somewhat larger API, I think anyone writing a new deriver should consider using ppx_type_conv. I cannot outright recommend that since I have not actually tried it (yet?), but it sounds worthwhile. [1]: http://opam.ocaml.org/packages/ppx_deriving/ppx_deriving.3.0/ [2]: https://whitequark.github.io/ppx_deriving/Ppx_deriving.html#2_Hygiene [3]: https://whitequark.github.io/ppx_deriving/Ppx_deriving_runtime.html -- whitequark