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 545207EEEF for ; Wed, 24 Jun 2015 02:26:04 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of asai@is.ocha.ac.jp) identity=pra; client-ip=133.65.64.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="asai@is.ocha.ac.jp"; x-sender="asai@is.ocha.ac.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of asai@is.ocha.ac.jp designates 133.65.64.10 as permitted sender) identity=mailfrom; client-ip=133.65.64.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="asai@is.ocha.ac.jp"; x-sender="asai@is.ocha.ac.jp"; 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@web.is.ocha.ac.jp) identity=helo; client-ip=133.65.64.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="asai@is.ocha.ac.jp"; x-sender="postmaster@web.is.ocha.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZAQAI+IlVlwpAQYVbg2Rfv1mGAAKBS0wBAQEBAQESAQEBAQEIFgdPhCMBAQQSKDkWCyElDwUgAQUBV4gMAQWqEz4xnFeFKQEBCAIBHwqLQIJagWFSFoMBgRQFjHyHA4RYhngBgXyUbzWBFReEGGCCSAEBAQ X-IPAS-Result: A0BZAQAI+IlVlwpAQYVbg2Rfv1mGAAKBS0wBAQEBAQESAQEBAQEIFgdPhCMBAQQSKDkWCyElDwUgAQUBV4gMAQWqEz4xnFeFKQEBCAIBHwqLQIJagWFSFoMBgRQFjHyHA4RYhngBgXyUbzWBFReEGGCCSAEBAQ X-IronPort-AV: E=Sophos;i="5.13,669,1427752800"; d="scan'208";a="137564208" Received: from web.is.ocha.ac.jp ([133.65.64.10]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Jun 2015 02:26:02 +0200 Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by web.is.ocha.ac.jp (Postfix) with ESMTP id 4F801996250 for ; Wed, 24 Jun 2015 09:26:00 +0900 (JST) Received: by pdbci14 with SMTP id ci14so17731739pdb.2 for ; Tue, 23 Jun 2015 17:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=p3XsjmkNKvN9kfXhOfSEQqz6yBs7f46tvF+gUPcUrJM=; b=ZYdIeW+h+zAc9ku1MtSSXUxhlWi6qT45mcEWbFbVvyqZ1fJn5iYLRrON6oLEeEwWtF 7brgGc9ceu/RpxkR4ElmrX3rNt/us6MzE48/iLRu0L21gq+AYbFUTx6U4db+GwgnTSVt 5wIIXuojy3D79T3do4qOeaA2ofvZtIn6nx1tFvgFqWjUAts2xjXQ1661HUOe3Chn8wtj peUE1DpSYd+gdpelgYt+wNyDPVNGPMSnlPES46uGkxQ2ekhXWNPszslUSnpwhN/044PC GHyVSoH/AOz6Lw2e116RksiW0qq7jFsqtpnku6GwUdLhs7CKXj5Oy5+j8R33gr3L1L70 xyNg== X-Gm-Message-State: ALoCoQmbeGW5YJvJZ9rOekaNibRYmJ/EP1G9uqubwhkB3WxW4a6Y8GsRVvziSWJ9O7dRLIbpYlL1AzKIwmRneRMxWXvcwURLgWrgzErL/B/48BhgGMdSsR5vtRpDU77xo6d9oVp9h6Bi X-Received: by 10.66.221.226 with SMTP id qh2mr19383688pac.64.1435105559903; Tue, 23 Jun 2015 17:25:59 -0700 (PDT) X-Received: by 10.66.221.226 with SMTP id qh2mr19383659pac.64.1435105559638; Tue, 23 Jun 2015 17:25:59 -0700 (PDT) Received: from localhost ([133.65.65.2]) by mx.google.com with ESMTPSA id pc9sm24594804pdb.6.2015.06.23.17.25.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2015 17:25:58 -0700 (PDT) Date: Wed, 24 Jun 2015 09:25:36 +0900 From: Kenichi Asai To: caml-list@inria.fr Message-ID: <20150624002536.GA5582@pllab.is.ocha.ac.jp> References: <20150623082651.GA5301@pllab.is.ocha.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150623082651.GA5301@pllab.is.ocha.ac.jp> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Caml-list] Labels at the module level? Thanks for all the answers! Let me ask one more (somewhat related) question. I want to share a type of messages between a client and a server (in communicating games students write to avoid segmentation fault caused by marshaling or a runtime error caused by bin-prot). One natural way to do it is to have a file message.ml: message.ml: ----- type t = int * int (* example type of messages *) ----- and use it in both the client and the server: client.ml: ----- let send (message : Message.t) = ... marshal the message and send to the server ... ----- server.ml: ----- let receive () : Message.t = ... unmarshal the message received from the client ... ----- In this case, however, students always have to write message.ml and declare Message.t even if it can be automatically inferred from the code of client.ml and server.ml. Ideally, I want to provide message.ml something like: message.ml: ----- type t = '_a ----- which signifies that the type Message.t can be anything as long as it is instantiated to exactly one type throughout the program (i.e., both in the client and the server). Students could then write only client.ml and server.ml. If they instantiate Message.t consistently, the program compiles fine; otherwise, compilation leads to a type error. Because the above definition of message.ml is not allowed, I defined: message.ml: ----- type t = int (* dummy type *) ----- and tried to override it: client.ml: ----- include Message type t = int * int ----- but it doesn't work. Would there be any way to impose a constraint that two types in two different modules to be the same without specifying the type itself? Sincerely, -- Kenichi Asai