From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 4206A7EEF8 for ; Sun, 9 Aug 2015 15:04:25 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPAQBoT8dVlwWCBoVdhFiDJMIOAoFpAQEBAQEBEgEBAQEBCBYHT0EDg2ABAQQjHQMBLgcBAQ4LGAICGA4CAlcGiEC2O3GEawKMA4RkAQEBAQEBBAEBAQEBAQEBEwEGgSKKL4Q+GDMHgmkvgRSNTYdDjGOBSYQllA+EMmKCTAEBAQ X-IPAS-Result: A0CPAQBoT8dVlwWCBoVdhFiDJMIOAoFpAQEBAQEBEgEBAQEBCBYHT0EDg2ABAQQjHQMBLgcBAQ4LGAICGA4CAlcGiEC2O3GEawKMA4RkAQEBAQEBBAEBAQEBAQEBEwEGgSKKL4Q+GDMHgmkvgRSNTYdDjGOBSYQllA+EMmKCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,639,1432591200"; d="scan'208";a="142368122" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Aug 2015 15:04:20 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 475116475; Sun, 9 Aug 2015 22:04:17 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (rabbit-172 [172.16.254.254]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 0737124D8; Sun, 9 Aug 2015 22:04:17 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=CdNC6EWg536875UPvDD1y3/3PKY=; b=EUsWMHr6MKtbqGdCF1L7oFR/RKhW Osxnz1dk540oVTFTY/AT48Dsm4ymf2l9XQjxqnzTyRq6Z7ESHHU/sAjUNx/INNW3 tetzZ17aNAnQ+612Ew1XuMoIliCFsVx3ASZoKsytBWnFN6UVmA5WGMrsJBEziChM bzRNriMLdiE7OuM= DomainKey-Signature: a=rsa-sha1; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=eTkq41RIhTSC5ySaLq7K5RNXyTeUF0cVphscEf3++QvNGZyYbUuKmDVCGhdWaXL+l+g62V4zswJr25JNwOP/aYJDXu11Yvvwx7LvL6RYtFAJVE4XVqs8GYoaXzuhfHv7lg8hVOgQFk/IMt84uMUGTJRil6ssifLhmsS4gDsMjwg=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 6B3BD83E0; Sun, 9 Aug 2015 22:04:38 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Jacques Garrigue In-Reply-To: Date: Sun, 9 Aug 2015 22:04:15 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Markus Mottl X-Mailer: Apple Mail (2.2102) Subject: Re: [Caml-list] Clever typing for client-server communication? On 2015/08/09 06:39, Markus Mottl wrote: >=20 > The object type trick is pretty neat and can actually be used with > module types, too. The advantage there is that whereas object types > are "flat", module types support more structure via submodules, e.g.: >=20 > module type Bla =3D sig module Foo : sig type t end end > type 'a t =3D 'foo_t constraint 'a =3D (module Bla with type Foo.t =3D '= foo_t) >=20 > Sadly, there is one significant shortcoming here: there does not seem > to be any way to exploit subtyping with module types. Not sure, but > the only reason for this seems to be that values of module type (i.e. > first-class modules) cannot be reasonably implemented with subtyping, > because unlike objects they don't carry around a dictionary at runtime > for looking up entries in the module. >=20 > Please correct me if I'm wrong, but from a pure typing perspective I > think that there should be no reason to disallow support for > expressing subtyping with module types. The compiler is already able > to infer whether module signatures satisfy subtyping relationships > anyway. The problem is that if you allow expression subtyping for module types, then I see no way to avoid its being applied to =E2=80=A6 modules. Which we= want to avoid, since the semantics of subtyping for modules is not the same as for expressions (i.e., modules require coercions). By the way, you can also define deep structures with object types, so I don=E2=80=99t see the advantage of using module types. For an example of nested object structures, you can see lablgtk, with its sub-object approach for signals. Jacques Garrigue=