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 6BC5B81792 for ; Tue, 25 Jun 2013 10:39:44 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=81.103.221.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com does not assert whether or not 81.103.221.47 is permitted sender) identity=mailfrom; client-ip=81.103.221.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.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@mtaout01-winn.ispmail.ntl.com) identity=helo; client-ip=81.103.221.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@mtaout01-winn.ispmail.ntl.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAL1WyVFRZ90vlGdsb2JhbABagmiBG785fhYOAQEBAQcNCQkUAyWCIwEBAQQnE08CAQgYChQQMiUBAQQTCBKHdQO6f48UOIMCYQOXQ5RUgig X-IPAS-Result: AuAAAL1WyVFRZ90vlGdsb2JhbABagmiBG785fhYOAQEBAQcNCQkUAyWCIwEBAQQnE08CAQgYChQQMiUBAQQTCBKHdQO6f48UOIMCYQOXQ5RUgig X-IronPort-AV: E=Sophos;i="4.87,935,1363129200"; d="scan'208";a="18902179" Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by mail3-smtp-sop.national.inria.fr with ESMTP; 25 Jun 2013 10:39:43 +0200 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130625083942.CQRA4711.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 25 Jun 2013 09:39:42 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130625083942.TWIY27539.aamtaout01-winn.ispmail.ntl.com@romulus.metastack.com> for ; Tue, 25 Jun 2013 09:39:42 +0100 Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id r5P8devD003581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Jun 2013 09:39:40 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 09:39:39 +0100 From: David Allsopp To: "OCaml List (caml-list@inria.fr)" Thread-Topic: [Caml-list] Anonymous sum types in functors Thread-Index: Ac5v3yzwFRXNb/EAR2+F06vEU1G49QAgAOoAABeQzmAACJ8XgAAn8HFA Date: Tue, 25 Jun 2013 08:39:39 +0000 Message-ID: References: <001601ce6fe1$a2ea9390$e8bfbab0$@metastack.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=IXlcok0kcmcA:10 a=SCxkbrXfzrIA:10 a=cTs9vV391PwA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=SGJpDYsEAAAA:8 a=ReYT_TnvebfiOipDcHcA:9 a=CjuIK1q_8ugA:10 a=dTth3pfvbawA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: RE: [Caml-list] Anonymous sum types in functors Kristopher Micinski wrote: > On Mon, Jun 24, 2013 at 5:39 AM, David Allsopp=20 > > wrote: > > Xavier Leroy wrote: > >> On 23/06/13 09:16, David Allsopp wrote: > >> > b) Is there a syntactically lighter way to write the module > definition? > >> > >> I would recommend naming your anonymous "struct": > >> > >> module Flag =3D struct > >> type t =3D A | B > >> let compare =3D compare > >> (* Other useful operations over flags, e.g. *) > >> let to_string =3D function A -> "A" | B -> "B" > >> end > > > > The "reason" for wanting to avoid that in this instance is the=20 > > specific application - the sets are actually bit masks and there are=20 > > about 50 of them (using a code generator, unsurprisingly). Given=20 > > that the ocamldoc output is already going to be interesting, I was=20 > > trying to avoid having 100 modules if possible :o) >=20 > This honestly sounds like something that you should be able to avoid=20 > in OCamlDoc. It seems sensible you should be able to mark things as=20 > "don't generate documentation for these", but I havent' seen such. (**/**) is mentioned in the manual for ocamldoc (and used in the standard l= ibrary, typically to "hide" the documentation for unsafe functions) - see 1= 5.2.2 of the reference manual. All these types do need documenting :o) But splitting the documentation for= each concept across two modules will necessarily make the documentation ph= ysically longer! David