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 C56107FBEB for ; Thu, 15 Jan 2015 10:42:14 +0100 (CET) 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: ArgEADSLt1SFBoIFXGdsb2JhbABbDoQigwXJAQKBWwEBAQEBBhgJKC6EDQEFIx0DASgKAwEBDgsYAgIYDgICISIUBhOIGAMQuxdwhGgCixENRYMwAQEBAQEBAQMBAQEBAQEVAQaBIYwugXczB4JoLoETiXGMK4FEjB+Fa4NTTGCCQwEBAQ X-IPAS-Result: ArgEADSLt1SFBoIFXGdsb2JhbABbDoQigwXJAQKBWwEBAQEBBhgJKC6EDQEFIx0DASgKAwEBDgsYAgIYDgICISIUBhOIGAMQuxdwhGgCixENRYMwAQEBAQEBAQMBAQEBAQEVAQaBIYwugXczB4JoLoETiXGMK4FEjB+Fa4NTTGCCQwEBAQ X-IronPort-AV: E=Sophos;i="5.09,402,1418079600"; d="scan'208";a="96496221" 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; 15 Jan 2015 10:41:53 +0100 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 6D269671F; Thu, 15 Jan 2015 18:41:50 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 901952564; Thu, 15 Jan 2015 18:41:49 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=VsUjOItHQX5weMVzt9JCSZKGIMI=; b=nTnW7IeP0MjlxZKZshF/0U8xDnEo 3iS7HLb+MLXaEX1Cyqlw1qBPsFLxw6KcPkvI6g0slYVYq3+k//yjltJe8DvRyI2S 4v4+UkT/HU9evkMU3pKdassfJNsV8WEaZ1yR53dO1EzWIgFcZZOaJ3R1AYytfifM fIa8n6vaei8kHxY= DomainKey-Signature: a=rsa-sha1; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=beU8TgMQmnDY0HaiNb3OWmjpuLmWNzO3/fbSdZ0sULvrtn6Ptm/mOnb4tU8TmgV+ivGYJHKK8JKtaEWRNiYRBizqPVTxreyv9igS9kB+1s6nVB3ESTEW+9UsVGkiUBF09Z3taDIP5uViD23GfW2WBZ54iDmTM3nugT4s/Etpxnw=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tanpopo.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 63DD24116; Thu, 15 Jan 2015 18:41:49 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Jacques Garrigue In-Reply-To: Date: Thu, 15 Jan 2015 18:41:49 +0900 Cc: =?utf-8?Q?Milan_Stanojevi=C4=87?= , Thomas Braibant , OCaml Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7A9D103C-132D-4614-A451-5C3E0F458F5B@math.nagoya-u.ac.jp> References: <877fwqqua0.fsf@study.localdomain> <87twzup6ie.fsf@study.localdomain> To: Leo P White X-Mailer: Apple Mail (2.1993) Subject: Re: [Caml-list] Quizz On 2015/01/15 02:24, Leo White wrote: >=20 > Milan Stanojevi=C4=87 writes: >=20 >>> The main problem is not so much syntax, as the fact it would require to= make >>> all definitions in the Types module mutually recursive. Not only that, = but >>> operations like path substitution need to be mutually recursive in the = same >>> way. So the question is whether the small gain in flexibility is worth = making the >>> implementation more complex. >>> (Note that an extra gain is that it becomes possible to expand a module= type >>> definition when leaving its scope) >>=20 >> In my work I mostly just wanted to be able to just do something like >> (module M : Intable with type t =3D t), i.e just specializing existing >> module type with "with type =3D" or "with type :=3D". >> Is this special case any easier to implement? >=20 > "with type t =3D" already works. I'm not sure, but I think that "with type > t :=3D" could indeed be implemented without the increased implementation > complexity that Jacques was referring to. Indeed it could. Module type names + non-parameterized constraints are ok, because you only = have to recurse on types, not concrete signatures. Jacques=