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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5B51B7FA57 for ; Wed, 23 Jul 2014 22:37:43 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.192.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.192.41 as permitted sender) identity=mailfrom; client-ip=209.85.192.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f41.google.com) identity=helo; client-ip=209.85.192.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qg0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAAkc0FPRVcAplGdsb2JhbABZhDcEgnTMOAGBAwgWDwEBAQEHCwsJEiuEAwEBAQMBEhEdARsdAQMBCwYFBAcDCioCAiIBEQEFARwGEyKICwEDCQicRmqLKIFygxCKYAoZJw1khjIRAQUOjz0HgniBTgWEbwKJVIxoi2yGYxgphRQhLw X-IPAS-Result: Ah0BAAkc0FPRVcAplGdsb2JhbABZhDcEgnTMOAGBAwgWDwEBAQEHCwsJEiuEAwEBAQMBEhEdARsdAQMBCwYFBAcDCioCAiIBEQEFARwGEyKICwEDCQicRmqLKIFygxCKYAoZJw1khjIRAQUOjz0HgniBTgWEbwKJVIxoi2yGYxgphRQhLw X-IronPort-AV: E=Sophos;i="5.01,719,1400018400"; d="scan'208";a="72588654" Received: from mail-qg0-f41.google.com ([209.85.192.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Jul 2014 22:37:42 +0200 Received: by mail-qg0-f41.google.com with SMTP id q107so2191979qgd.14 for ; Wed, 23 Jul 2014 13:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nlVDSV19Uj1PQYlYYMzz15N14WJTQr4R/adSq3j7ZWU=; b=ag02HarqSLODsa/BrYyUIaLuVKD9iYq+TAYDc27uvakGG+v0eJ72S3HVvX2udruQDl +Yk7b26KoLZxc6bPZM2K0bKbwduu7TD6+B7SaHKqV+Xm9DJuGQtn4NviBcwA4jwJsI6V s+7sCiB9D1cyDK1z2GXOxTVUumlL/ZyAzRZFu7SX9iV1Oio8gDIE2xY8Hxh6V4ynWSIK ijZJO95vdylYCew6nggWMcgcKcbFJtcx2cwJy6ZjRCHpHlfJUEtK3YMPxDq3sFiTxA0g evCi7tP+UrD6q+9vreYa5qHxNAjsp4rSGwInQdDoBAQtUsvWW1TArVs/C6sbw1WyKGC0 nKUQ== X-Received: by 10.224.122.83 with SMTP id k19mr5794541qar.78.1406147861117; Wed, 23 Jul 2014 13:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.33.14 with HTTP; Wed, 23 Jul 2014 13:37:20 -0700 (PDT) In-Reply-To: References: <0618b5ce9c054e91507c03eae7e7de0c@whitequark.org> From: Yotam Barnoy Date: Wed, 23 Jul 2014 16:37:20 -0400 Message-ID: To: Peter Zotov Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7bf0c346c38cfa04fee24f70 Subject: Re: [Caml-list] [ANN] ppx_deriving 0.1 --047d7bf0c346c38cfa04fee24f70 Content-Type: text/plain; charset=UTF-8 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. Any idea where I can find some info on ocaml's upcoming implicits? A google search was not particularly helpful. 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 > --047d7bf0c346c38cfa04fee24f70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, I was just making some suggestions based on experience= I have with haskell's deriving, which I use all the time, and trying t= o bring as much of that ease of use as possible to ocaml.

Any idea where I can find some info on ocaml's upcoming implicits? A go= ogle search was not particularly helpful.



On Wed, Jul 23, 2014= at 4:19 PM, Peter Zotov <whitequark@whitequark.org>= wrote:
On 2014-07-23 18:36, Yotam B= arnoy 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 =3D b && b =3D c) ...'

or =C2=A0'T_.show x ...'

which allows you to keep the infix notation for =3D 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:whitequ= ark@sipnet.ru

--047d7bf0c346c38cfa04fee24f70--