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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id B241E7ED34 for ; Sat, 7 Jul 2012 06:47:42 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.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=mail1-smtp-roc.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 (mail1-smtp-roc.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=mail1-smtp-roc.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 (mail1-smtp-roc.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=mail1-smtp-roc.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: AvYEAPO+90+FBoIF/2dsb2JhbABFhWagbZITghgBAQQBIwQZAwEqCwEBAwsLGgIJDwcHAgJFEiuHawMGBAymcW6DRgGFTQNUiH0BBoEgjxMyYIhLjG+BEol0hH2Cbg X-IronPort-AV: E=Sophos;i="4.77,541,1336341600"; d="scan'208";a="165941910" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Jul 2012 06:47:40 +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 AE01762D6; Sat, 7 Jul 2012 13:47:36 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (camel-172.math.nagoya-u.ac.jp [172.16.254.4]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 4F9814205; Sat, 7 Jul 2012 13:47:36 +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=SOYojxq8b95zOVeVjGWZXny8VvQ=; b=rtgjvht/x6NHQTsAm3/5jOa/JmMc bmAgkQrKXoeyTzejT8Dp87UBE0oRY+oGs7jMhPXETF2L388UOxziXQx9MF+2sBzo konL6PQ8oRA3XGhuKSlOTsahsXoJD/pHylK6hmCLV2m2/A3bHegpEAjJ5cC07C+f MBt7TEr8fDSdu0o= 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=vis2jr520eQyx54taEw/0Dc9xBWd3hCB05Kf/OztxMMNuGIPQ3IpHZ4vq3x3iThBEYLNxegevJYfnt+wl4yrqPArL2L1PjHj60GcOpDDf+xTzqIVoFe/z3/zTaRYmcBQvtaoLJMtvCYeiIXcLOf4YoxKVX8UjzmK/TDhBaJIeTw=; 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 BEFE34151; Sat, 7 Jul 2012 09:13:58 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Jacques Garrigue In-Reply-To: <4FF73E39.5060405@ircam.fr> Date: Sat, 7 Jul 2012 09:13:57 +0900 Cc: Mailing OCaML Content-Transfer-Encoding: quoted-printable Message-Id: <7408FAD9-6B1F-4881-953C-216901EAE8B3@math.nagoya-u.ac.jp> References: <4FF4C98F.2030703@ircam.fr> <4FF73E39.5060405@ircam.fr> To: jean-louis.giavitto@ircam.fr X-Mailer: Apple Mail (2.1084) Subject: Re: [Caml-list] Problem of type equality in a single definition (was: In 3.12 and 4.0, erratic message "The implementation tt.ml does not match the interface tt.cmi") I could reproduce this bug with 3.11 and 3.12. It appears to be fixed in the latest version of 4.00 (and trunk). (By the way, bugs should go to the bug tracker...) Jacques Garrigue On 2012/07/07, at 4:36, Jean-Louis Giavitto wrote: > Dear all, > I have circumscribed my initial problem and I am able to produce it on a = simple case. >=20 >=20 > I have a signature Classdef.mli restrcted to >=20 > class virtual ['a, 'b, 'c] cl0 : > object > constraint 'c =3D < m : 'a -> 'b -> int; .. > > end >=20 > class virtual ['a, 'b] cl1 : > object > method virtual m : 'a -> 'b -> int > method virtual raise_trouble : 'a > end >=20 > class virtual ['a, 'b] cl2 : > object > method virtual as_cl0 : ('a, 'b, ('a, 'b) cl1) cl0 > end >=20 > then, in another module that contains only the following type declaration >=20 > type refer =3D > { > poly : 'a 'b 'c . (('b, 'c) #Classdef.cl2 as 'a); > } >=20 > raise the error: >=20 > File "anotherModule.ml", line 1, characters 0-1: > Error: The implementation anotherModule.ml > does not match the interface (inferred signature): > Type declarations do not match: > type refer =3D { poly : 'a 'b 'c. ('b, 'c) #Classdef.cl2 as 'a; } > is not included in > type refer =3D { poly : 'a 'b 'c. ('b, 'c) #Classdef.cl2 as 'a; } > The types for field poly are not equal. >=20 >=20 > Note that > - if I suppress the method raise_trouble > - or if neither 'a nor 'b appear in the type of this method, > then everything works fine. >=20 > Can someone explain to me this behavior? (the two files are in the attach= ed tarball): > . First, I don't understand which instances of type poly are compared: > there is only one single definition of this type and no use. > . And second, I don't understand why adding a method will change the > behavior. >=20 > Many thanks in advance, > Jean-Louis Giavitto >=20 >=20 >=20 > ------------------------------------------------------- > Le 22/07/64 20:59, Jean-Louis Giavitto a =C3=A9crit : >> Hello. >> if anyone could give me some hints on the following problem... >>=20 >>=20 >> I have a file tt.ml which reduces to >>=20 >> type typedef =3D { >> isa : 'a 'rep 'cell . >> (('rep, int, int, int, int, int) #Collection.collection as 'a); >> } >>=20 >> The mli file is exactly the same has the ml file. 'collection' is a >> virtual class declared in file collection.ml and signature in >> collection.mli. >>=20 >> tt.ml compile without problems. However, if I replace (in tt.ml and >> tt.mli) one of the 'int' parameter by a type variable: >>=20 >> type typedef =3D { >> isa : >> 'a 'rep 'cell . >> (('rep, 'cell, int, int, int, int) #Collection.collection >> as 'a); >> } >>=20 >> then I have the following message (with the 4.0 compiler): >>=20 >> File "tt.ml", line 1: >> Error: The implementation tt.ml does not match the interface tt.cmi: >> Type declarations do not match: >> type typedef =3D { >> isa : >> 'a 'rep 'cell. >> ('rep, 'cell, int, int, int, int) #Collection.collection as 'a; >> } >> is not included in >> type typedef =3D { >> isa : >> 'a 'rep 'cell. >> ('rep, 'cell, int, int, int, int) #Collection.collection as 'a; >> } >> File "tt.ml", line 2, characters 5-112: Actual declaration >> The types for field isa are not equal. >>=20 >>=20 >> - The problem appears with the compiler 3.12 but also 4.0 (a similar >> error (5622) was reported but was not reproducible with 4.0). >> - I have no problem if I drop the .mli file. >> - The error seems sensitive to the definition of the class 'collection': >> I was not able to reproduce it with a much simpler definition of >> collection. >> - I have the same error if I replace more 'int' parameter by type >> variables. >>=20 >> Have you any clues? >> Jean-Louis Giavitto. >=20 >=20 > --=20 > Jean-Louis Giavitto > Ircam CNRS UMR STMS 9912 =E2=80=93 UPMC =E2=80=93 Inria > 1, place Igor Stravinsky, 75004 Paris >=20 > http://repmus.ircam.fr/giavitto > http://mgs.spatial-computing.org >=20 > --=20 > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >=20 >