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 57DE97FA4D; Mon, 28 Jul 2014 14:26:19 +0200 (CEST) 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: AtsFAP4/1lOwOmd9/2dsb2JhbABZg2BXgieuAAEBAQEGgTqaFIdFAYEod4QDAQEEATgCPwULBAcYLiwrBhMIiDIMCb1TF4V8g2WEXYEOB4RKBYRzAoV2nFOIWoNOOC8 X-IPAS-Result: AtsFAP4/1lOwOmd9/2dsb2JhbABZg2BXgieuAAEBAQEGgTqaFIdFAYEod4QDAQEEATgCPwULBAcYLiwrBhMIiDIMCb1TF4V8g2WEXYEOB4RKBYRzAoV2nFOIWoNOOC8 X-IronPort-AV: E=Sophos;i="5.01,749,1400018400"; d="scan'208";a="87276448" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP; 28 Jul 2014 14:26:18 +0200 Received: by mail.whitequark.org (Postfix, from userid 33) id A00DC4E715; Mon, 28 Jul 2014 12:26:17 +0000 (UTC) To: Yotam Barnoy 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: Mon, 28 Jul 2014 16:26:17 +0400 From: Peter Zotov Cc: Ocaml Mailing List , caml-list-request@inria.fr In-Reply-To: References: <0618b5ce9c054e91507c03eae7e7de0c@whitequark.org> Message-ID: <0682fe324f2fc47e73b7701a635918d7@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.0.1 Subject: Re: [Caml-list] [ANN] ppx_deriving 0.1 On 2014-07-24 00:37, Yotam Barnoy wrote: > OK, I was just making some suggestions based on experience I have with > haskell's deriving, which I use all the time, and trying to bring as > much of that ease of use as possible to ocaml. Thank you for the suggestion. I see some cases where modules would be useful, (including, eventually, implicits), but as most deriving plugins generate a single function now, I think it would be pointless to generate such modules. > Any idea where I can find some info on ocaml's upcoming implicits? A > google search was not particularly helpful. There are two articles by Alain Frisch: http://www.lexifi.com/blog/implicit-values http://www.lexifi.com/blog/implicit-arguments They get the general idea across, but do not represent the ongoing work. The ongoing work is being done in this git repository: https://github.com/def-lkb/ocaml/commits/implicit-module As far as I know, it is not yet documented in any way and it is not clear whether it will be merged in OCaml at all. However, I have high hopes for this feature. > > On Wed, Jul 23, 2014 at 4:19 PM, Peter Zotov > wrote: > >> On 2014-07-23 18:36, Yotam Barnoy wrote: >> >>> Very nice. >>> >>> I've never used any of the deriving extensions before, but I have >>> an >>> aesthetic suggestions. >> >> I humbly suggest trying to use it before proposing aesthetic >> changes. >> >>> 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. >> >> I believe this is best left to the upcoming implicits, which will >> hopefully be merged soon. >> >> I have based the current design on existing patterns across OCaml >> ecosystem; I don't want to change the way people structure their >> modules, I want to reduce the amount of boilerplate to write. >> >> -- >> Peter Zotov >> sip:whitequark@sipnet.ru -- Peter Zotov