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.1 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 E8543BC69 for ; Sat, 24 Nov 2007 01:30:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM//RkdA6ba6kGdsb2JhbACPPQEBAQEHAgYkBw X-IronPort-AV: E=Sophos;i="4.21,459,1188770400"; d="scan'208";a="19623335" Received: from nf-out-0910.google.com ([64.233.182.186]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Nov 2007 01:30:02 +0100 Received: by nf-out-0910.google.com with SMTP id e27so2687845nfd for ; Fri, 23 Nov 2007 16:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; bh=f7+z2ifgjyXL8lva8jYtGM+JoU/eM7mHEx2qwbk6N50=; b=Y1/oyT/g1iVJFufCqLCliObt5Kz2niDCRb8zcojeZ4xlqT+oNpyQz7WIjvG4Gd0Iw5lDuQTof/xHQn0Ws3kSbS73KXEGAtV43lE5VRqJjQstCR2hohSoxW8ebpPs6FBBJNKTfKzxdean8BPB0AehQShE7Y9/ymwQxpJi9Cz+niU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=R+3GgFdFM9diKaejiH33eMMzm7Zb2eqgR4cczOE4ibL3F6MeipFfNv+DbR4LpybuJ7YNHO8jspqaQJxP7SSmxvVJ+YZam55dvL6+BfXvKMsvRZ9Jct6uQPX4JqKlkQvEywtfG6KkFrCv4NGGbH1cWfY8+qQ4vWBTYevcYODAYq4= Received: by 10.86.68.20 with SMTP id q20mr1070275fga.1195864201638; Fri, 23 Nov 2007 16:30:01 -0800 (PST) Received: from localhost ( [82.122.248.16]) by mx.google.com with ESMTPS id 22sm3837122fkr.2007.11.23.16.29.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Nov 2007 16:30:00 -0800 (PST) Received: by localhost (sSMTP sendmail emulation); Sat, 24 Nov 2007 01:31:11 +0100 Date: Sat, 24 Nov 2007 01:31:11 +0100 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] weird behavior with built-in ignore function (a bug?) Message-ID: <20071124003110.GA32596@localhost> References: <200711231109.47460.peng.zang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200711231109.47460.peng.zang@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: Julien Moutinho X-Spam: no; 0.00; bug:01 val:01 foo:01 val:01 foo:01 transforming:01 ocamlc:01 ocamlc:01 pervasives:01 ocaml:01 bool:01 bool:01 bug:01 ocaml:01 23,:98 On Fri, Nov 23, 2007 at 11:09:44AM -0500, Peng Zang wrote: > 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. [..] AFAICS it has been fixed in the release310 branch: http://caml.inria.fr/mantis/view.php?id=4350 % git checkout release310 Switched to branch "release310" % make ocamlc [...] % ./ocamlc -i peng__071123.ml type 'a fruit = 'a and 'a veggie = 'a and ('a, 'b) kitchen = { source : < make : 'a fruit >; sink : < trans : 'a fruit -> 'b veggie >; } val bar : < trans : 'a -> 'b; .. > -> 'a -> 'b val foo : < make : 'a fruit > -> < trans : 'a fruit -> 'b veggie > -> unit % git-log --grep='PR#4350' commit 4240263b7cbe15e87cc24e797aac6917eacb9f71 Author: garrigue Date: Mon Oct 29 04:40:34 2007 +0000 PR#4350 % git-revert 4240263b % make ocamlc % ./ocamlc -i peng__071123.ml type 'a fruit = 'a and 'a veggie = 'a and ('a, 'b) kitchen = { source : < make : 'a fruit >; sink : < trans : 'a fruit -> 'b veggie >; } val bar : < trans : 'a -> 'b; .. > -> 'a -> 'b val foo : < make : 'a fruit > -> < trans : 'a fruit -> '_b veggie > -> unit % git-reset --hard 'HEAD^' > 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? Perhaps the fact that Pervasives.ignore is defined like that: external ignore : 'a -> unit = "%ignore" BTW be aware that: % ocaml Objective Caml version 3.10.1+dev2 (2007-11-20) # ignore == ignore;; - : bool = false # let ignore _ = ();; val ignore : 'a -> unit = # ignore == ignore;; - : bool = true > 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 HTH, Julien.