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 409947F747 for ; Fri, 8 Aug 2014 10:20:18 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of frederic.bour@lakaban.net) identity=pra; client-ip=94.23.239.155; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="frederic.bour@lakaban.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of frederic.bour@lakaban.net designates 94.23.239.155 as permitted sender) identity=mailfrom; client-ip=94.23.239.155; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="frederic.bour@lakaban.net"; 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.lakaban.net) identity=helo; client-ip=94.23.239.155; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="postmaster@mail.lakaban.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcUANqH5FNeF++b/2dsb2JhbABagmItgSeCXRqEe60pnwgBgSl3hAQBBSMEGQEBNwEPCwQ+AgIhNgYTiC4DFa16d4UCAQWLAQ2FdxEGjR+CLQeCeYFSjwiDDIgNggmHJIcghi6EQw X-IPAS-Result: AmcUANqH5FNeF++b/2dsb2JhbABagmItgSeCXRqEe60pnwgBgSl3hAQBBSMEGQEBNwEPCwQ+AgIhNgYTiC4DFa16d4UCAQWLAQ2FdxEGjR+CLQeCeYFSjwiDDIgNggmHJIcghi6EQw X-IronPort-AV: E=Sophos;i="5.01,823,1400018400"; d="scan'208";a="88688742" Received: from lakaban.net (HELO mail.lakaban.net) ([94.23.239.155]) by mail2-smtp-roc.national.inria.fr with ESMTP; 08 Aug 2014 10:20:17 +0200 Received: from [192.168.0.31] (cpc27-cmbg15-2-0-cust159.5-4.cable.virginm.net [86.27.188.160]) (Authenticated sender: defre@ygg-drasil.fr) by mail.lakaban.net (Postfix) with ESMTPSA id 45FDC1200019; Fri, 8 Aug 2014 10:16:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lakaban.net; s=default; t=1407485808; bh=CiaeI+utNK4pqB5LuCNXddpp5ALklAHrnSZWWFuhod0=; h=Date:From:Subject:To:Cc:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=dVr3v3wD8dsxaUZVFurAzl3uYdPioJ8mb3Ga27r+EIYzuVv+kKY3wMRIjeINnGUIi zj7PL13/reerHu5k2tgJ48UVmJ1L5YusMHC+xiT7v0kw4DZLmFHk/YS8Oh3GngoLY1 dVtx9qKoB4Z1EP+68QYHzyU+GTYPSF975e3hhR8A= Date: Fri, 08 Aug 2014 08:20:32 +0001 From: =?iso-8859-1?b?RnLpZOlyaWM=?= Bour To: Trevor Smith Cc: =?iso-8859-1?b?VPZy9ms=?= Edwin , caml-list@inria.fr Message-Id: <1407485972.2631.1@mail.lakaban.net> In-Reply-To: References: <53E24B96.8080402@etorok.net> X-Mailer: geary/0.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-DDljkYu9nFnFRv6+Jiuz" Subject: Re: [Caml-list] Type Constraints and .mli --=-DDljkYu9nFnFRv6+Jiuz Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le jeu. 7 ao=C3=BBt 2014 =C3=A0 23:06, Trevor Smith=20 a =C3=A9crit : > Edwin, >=20 > Thank you for your response. >=20 > You are correct that the "val t" in my example should read "type t". >=20 > My main goal is one of readability: I want to have large swathes of=20 > the codebase only use the immutable interface. A few, but very few,=20 > parts of the codebase will use the mutable interface. Ideally, I want=20 > the developer reading the .mli files to quickly and easily understand=20 > what interfaces do what. The standard way of adding the type=20 > constraints add a lot of syntax and make it (slightly) harder to=20 > read. My entire question is sort of a nitpick. Hi, I am not sure I understood your problem but I'll try to provide=20 some info. The standard way of adding "type constraints" is by just exposing the=20 equality between types in the interface. In your case: character.mli: type t =3D CharacterImpl.t val create : string -> t val name : t -> string mCharacter.mli: type t =3D CharacterImpl.t val create : string -> t val name : t -> string val set_name : t -> string -> unit Which is what express "CharacterSig with type t =3D CharacterImpl.t": create a new signature by taking "CharacterSig" and replacing "type t"=20 by "type t =3D CharacterImpl.t". --=-DDljkYu9nFnFRv6+Jiuz Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le jeu. 7 ao=C3=BBt 2014 =C3=A0 23:06, Trevor Smith <trevorsummerssmith@= gmail.com> a =C3=A9crit :
Edwin,

Thank = you for your response.

You are correct that the "v= al t" in my example should read "type t".

My main = goal is one of readability: I want to have large swathes of the codebase on= ly use the immutable interface. A few, but very few, parts of the codebase = will use the mutable interface. Ideally, I want the developer reading the .= mli files to quickly and easily understand what interfaces do what. The sta= ndard way of adding the type constraints add a lot of syntax and make it (s= lightly) harder to read. My entire question is sort of a nitpick.

Hi, I am not sure I understood your problem b= ut I'll try to provide some info.

The standard way of ad= ding "type constraints" is by just exposing the equality between types in t= he interface. In your case:

character.mli:
=   type t =3D CharacterImpl.t
  val create : string -> t
=   val name : t -> string

mCharacter.mli:
  type = t =3D CharacterImpl.t
  val create : strin= g -> t
  val name : t -> string
<= font face=3D"monospace">  val set_name : t -> string -> unit

Which is what express "CharacterSig wit= h type t =3D CharacterImpl.t":
create a new signature by taking "= CharacterSig" and replacing "type t" by "type t =3D CharacterImpl.t".
=


= --=-DDljkYu9nFnFRv6+Jiuz--