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 E321C7EF28 for ; Fri, 26 Jun 2015 10:12:22 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of bmillwood@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="bmillwood@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of bmillwood@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="bmillwood@janestreet.com"; 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@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQAgA9CI1VnHDIaSZbDoNXXwaDGKpzK44vgg8BCYV4AoE0B0wBAQEBAQESAQEBAQEGFglPhCMBAQMBEhEdAQEsBQYBBAsLCxodAgIiEgEFAQoSBhMSEId4AwoIAwqrWz4xik9whGQBBYtmA4V9AQEBAQEBBAEBAQEBAQEBAQESBgqLQIJagWFHBAeCLQwvEoExhV8KjiCEWIZ6gXyPKIVJEiOBFhEGg0s/boJIAQEB X-IPAS-Result: A0BQAgA9CI1VnHDIaSZbDoNXXwaDGKpzK44vgg8BCYV4AoE0B0wBAQEBAQESAQEBAQEGFglPhCMBAQMBEhEdAQEsBQYBBAsLCxodAgIiEgEFAQoSBhMSEId4AwoIAwqrWz4xik9whGQBBYtmA4V9AQEBAQEBBAEBAQEBAQEBAQESBgqLQIJagWFHBAeCLQwvEoExhV8KjiCEWIZ6gXyPKIVJEiOBFhEGg0s/boJIAQEB X-IronPort-AV: E=Sophos;i="5.13,683,1427752800"; d="scan'208";a="167403320" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 26 Jun 2015 10:12:22 +0200 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z8OkG-0001mK-IB for caml-list@inria.fr; Fri, 26 Jun 2015 04:12:20 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BVjQlk-AAACC0-QI; 2015-06-26 04:12:20.517088-04:00 Received: from mail-qk0-f172.google.com ([209.85.220.172]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1Z8OkG-0000mM-EA for caml-list@inria.fr; Fri, 26 Jun 2015 04:12:20 -0400 Received: by qkeo142 with SMTP id o142so51617356qke.1 for ; Fri, 26 Jun 2015 01:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mcno3dmyKGxPaNf3dw2wH2+nYXotV5ralY9G+PnL2l0=; b=Ndwh5fk/Cfe39qj2O8FKPsmPSb6SsUoDZoEm8YhbSYRRwjs9rwKT27B/X2jF5cmjQO GtctCIwAOMqvEEtDTMXxxPlNjt2h4tK0ONU4ErMYN5b4wgvw7i/Cf3AoXbh0ihHCFY46 LhpgXN5uq7Wop7RaXFE0hZdX3Ebsj930KmhjM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mcno3dmyKGxPaNf3dw2wH2+nYXotV5ralY9G+PnL2l0=; b=SLDoAdMj/dNZuK4HRpdpRti92aSiOZA6Ol78i4I0RWnpzG8VK2H1R2ykxEFUWobuam 13InpDA4Y12CHbhcykUhzv1DEaevjxM2sDI1MzoYNJ/JtRcwkQjvR2QY4AxVBJlz3S0E Ib3KmYFGn8Sx3r6beI3EzCtWVKs5S9hvT6b8cfgg37tdtsXy9zjdPsTwf/tNb7GPqs8J AgCZAC6GsBeIkaMVtnqY/nnyBrDUl5QDmXxww5J4sVnYoFlKrkKcjKsLn5puPHLopGDq +n1J729iZTvqwy9gVQarlQuzy2RLXogfJGxstVsyAOkJrf6IZSt6OKEY08HNgQOVdDUY iHqw== X-Gm-Message-State: ALoCoQmekjR9UOuUY8kfTtN6LQBG28RaG/g5g5bHbahaSOfTQH/EkY9SjatoaptRucl3Vx21Pn9DTbTrh6w9Cr3fRYYN3OmMgUr67fzmzk0VytNeLEzp0HeRttViRtfFwKRpHJoj/0KO X-Received: by 10.140.151.15 with SMTP id 15mr495152qhx.104.1435306340181; Fri, 26 Jun 2015 01:12:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.151.15 with SMTP id 15mr495145qhx.104.1435306340059; Fri, 26 Jun 2015 01:12:20 -0700 (PDT) Received: by 10.96.223.194 with HTTP; Fri, 26 Jun 2015 01:12:19 -0700 (PDT) In-Reply-To: <20150624002536.GA5582@pllab.is.ocha.ac.jp> References: <20150623082651.GA5301@pllab.is.ocha.ac.jp> <20150624002536.GA5582@pllab.is.ocha.ac.jp> Date: Fri, 26 Jun 2015 09:12:19 +0100 Message-ID: From:Ben Millwood To:Kenichi Asai Cc:caml users Content-Type: multipart/alternative; boundary=001a113746cc8b25fa0519674cb8 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Labels at the module level? --001a113746cc8b25fa0519674cb8 Content-Type: text/plain; charset=UTF-8 Instead of having Client and Server depend on Message, consider having Check_message_types depend on both Client and Server, and in check_message_types.ml you have: let check_message_types_are_equal (x : Client.t) : Server.t = x On 24 June 2015 at 01:25, Kenichi Asai wrote: > 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 > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a113746cc8b25fa0519674cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Instead of having Client and Server depend on Message, con= sider having Check_message_types depend on both Client and Server, and in <= a href=3D"http://check_message_types.ml">check_message_types.ml you hav= e:

let check_message_types_are_equal (x : Client.t) : Se= rver.t =3D x

On 24 June 2015 at 01:25, Kenichi Asai <asai@is.ocha.ac.jp>= wrote:
Thanks for all the answers= !=C2=A0 Let me ask one more (somewhat related)
question.=C2=A0 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 =3D int * int (* example type of messages *)
-----

and use it in both the client and the server:

client.ml= :
-----
let send (message : Message.t) =3D
=C2=A0 ... marshal the message and send to the server ...
-----

server.ml= :
-----
let receive () : Message.t =3D
=C2=A0 ... 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 c= lient.ml and server.ml.=C2=A0 Ideally, I want to provide
message.= ml something like:

message.= ml:
-----
type t =3D '_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).=C2=A0 Students could then write only
client.ml= and = server.ml.=C2=A0 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 =3D int (* dummy type *)
-----

and tried to override it:

client.ml= :
-----
include Message
type t =3D int * int
-----

but it doesn't work.=C2=A0 Would there be any way to impose a constrain= t
that two types in two different modules to be the same without
specifying the type itself?

Sincerely,

--
Kenichi Asai

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a113746cc8b25fa0519674cb8--