From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p83BgadT026457 for ; Sat, 3 Sep 2011 13:42:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioCAPERYk5V2gB4i2dsb2JhbABCqQABAQEKCwsbJoFGAQEFJyAyEAtGFCghiAioRY17DoZcBKQ9 X-IronPort-AV: E=Sophos;i="4.68,324,1312149600"; d="scan'208";a="118215835" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 03 Sep 2011 13:42:37 +0200 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.93.239]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id B900BE641A4; Sat, 3 Sep 2011 13:42:30 +0200 (CEST) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1Qzoc3-0004kw-E9; Sat, 03 Sep 2011 13:42:15 +0200 Date: Sat, 3 Sep 2011 13:42:14 +0200 From: Guillaume Yziquel To: Christophe Papazian Cc: Goswin von Brederlow , caml-list@inria.fr Message-ID: <20110903114214.GZ15100@localhost> References: <87ty8uc5ph.fsf@frosties.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p83BgadT026457 Subject: Re: [Caml-list] Odd failure to infer types Le Saturday 03 Sep 2011 à 12:31:59 (+0200), Christophe Papazian a écrit : > The type of [] is 'a list. This is (strong) polymorphism. Calling a > function 'int list -> ?' on [] doesn't not > remove the polymorphism of []. However, an '_a list array is not > polymorphism, it's just the compiler who don't know > yet the type inside the lists. And as you give him [], he can't > deduce the type. > > As an example you can do this : > > let s = [] in 1::s, 'a'::s, [|s|] ;; > > And it still doesn't know... Ah, right... not the most obvious case though for let-polymorphism. A perhaps more talking example would be let f x = x in (f 1, f "1") While let-polymorphism makes obvious sense when using f as a function, it's less intuitive when it used on a function argument such as [], though quite logical. Personnally, I find it quite weird to have the value restriction on list refs, but not on lists: # let x = [];; val x : 'a list = [] # let x = ref [];; val x : '_a list ref = {contents = []} # let x = [] in (List.map print_string x), (List.map print_int x);; - : unit list * unit list = ([], []) # let x = ref [] in (List.map print_string !x), (List.map print_int !x);; Error: This expression has type string list but an expression was expected of type int list Using the print function on a state which doesn't have [] as first component of the tuple would likely fixate properly the '_a, though. -- Guillaume Yziquel