From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B3541BC69 for ; Fri, 23 Nov 2007 17:09:53 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJ6KRkfRVaKymGdsb2JhbACPNAEBAQEHBAQTGA X-IronPort-AV: E=Sophos;i="4.21,458,1188770400"; d="scan'208";a="19614124" Received: from el-out-1112.google.com ([209.85.162.178]) by mail4-smtp-sop.national.inria.fr with ESMTP; 23 Nov 2007 17:09:53 +0100 Received: by el-out-1112.google.com with SMTP id r27so1365498ele for ; Fri, 23 Nov 2007 08:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:content-type:content-transfer-encoding:content-disposition:message-id; bh=AYFwba5dC2r4X6bgsN+yosfnMLZn5XFbmYcn+PL1Z4k=; b=DcDJD9/clMRHD9ScDMPsW4LhlYjNHp4bbxDeIaNdR0Aj95c5uh3qiZ6riy1GN3TW4TYCHo8A6MgoZCYRp7+MUVR9xxlqqDtPhxHrcaNaTlzCq+v9OxSs4rSD7QcdTUXbTcuUx1iY/7cmSC7ApYEgTnsOPOY1bXsZ8Zs/wVEhHss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:content-type:content-transfer-encoding:content-disposition:message-id; b=Sty3PA0ebGDyjrj5P/gwiDh/enAuKzLXtArpVQhxaD/hQO8mrmv4I7EdKN74QAmDtTvE8jsFsYkl8g9LQt7lApSyOqud12PbRr9MpYA/dxrhbFvlKjN9a6DeajtyTMRZZvJCWNd4Pdg71agNLKBFE+TXfn8VBlrXBqJVw9HEc2E= Received: by 10.142.83.4 with SMTP id g4mr2044371wfb.1195834191161; Fri, 23 Nov 2007 08:09:51 -0800 (PST) Received: from tama-chan ( [24.99.180.210]) by mx.google.com with ESMTPS id 14sm3328156wrl.2007.11.23.08.09.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Nov 2007 08:09:50 -0800 (PST) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: weird behavior with built-in ignore function (a bug?) Date: Fri, 23 Nov 2007 11:09:44 -0500 User-Agent: KMail/1.9.7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711231109.47460.peng.zang@gmail.com> X-Spam: no; 0.00; bug:01 hash:01 val:01 foo:01 val:01 foo:01 transforming:01 bug:01 ocaml:01 peng:98 peng:98 polymorphic:01 polymorphic:01 inferred:02 objects:02 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have run into what appears to be very odd behavior with the built-in function "ignore". I will demonstrate below. It's a little complicated, but it's the smallest testcase I could make it: # type 'a fruit = 'a and 'b veggie = 'b and ('a,'b) kitchen = { source : ; sink : 'b veggie>; } ;; # let bar sink x = sink#trans x;; val bar : < trans : 'a -> 'b; .. > -> 'a -> 'b = # let foo src snk = let m = { source = src; sink = snk } in ignore (bar m.sink m.source#make); ignore (bar m.sink m.source#make); () ;; val foo : < make : 'a fruit > -> < trans : 'a fruit -> '_b veggie > -> unit = Basically, we have two objects. One is producing fruits (source) and the other is transforming them into vegetables (sink). Note the inferred typesig of foo, it thinks the trans method returntype is '_b veggie. This seems strange. I think it should return a fully polymorphic 'b veggie. To verify. I now re-define foo without the use of ignore: # let foo src snk = let m = { source = src; sink = snk } in let _ = bar m.sink m.source#make in let _ = bar m.sink m.source#make in ();; val foo : < make : 'a fruit > -> < trans : 'a fruit -> 'b veggie > -> unit = This time the return type for trans is fully polymorphic! Using ignore as in the first case broke something. For a strange turn, I make my own ignore function and redefine foo with that: # let myignore x = ();; val myignore : 'a -> unit = # let foo src snk = let m = { source = src; sink = snk } in myignore (bar m.sink m.source#make); myignore (bar m.sink m.source#make); () ;; val foo : < make : 'a fruit > -> < trans : 'a fruit -> 'b veggie > -> unit = This also yields returns a fully polymorphic veggie! So it's something unique to the build-in ignore function? So now my puzzling question: what is going on? What is wrong with the build-in ignore function that would make it mess up the return type of the trans method? Is this a bug? Thanks, Peng PS. I'm using OCaml 3.09.3, haven't tried with 3.10 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHRvtLfIRcEFL/JewRAlaUAKDILTX5yx7vsK0z8qRWFXMosywfUgCfcFqv zfcI8DJ4qOuDzF+S3zsrFBM= =fBnk -----END PGP SIGNATURE-----