From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id C7E74BB81 for ; Wed, 8 Dec 2004 04:30:55 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iB83Ut4g009420 for ; Wed, 8 Dec 2004 04:30:55 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA22049 for ; Wed, 8 Dec 2004 04:30:54 +0100 (MET) Received: from mail.kaba.or.jp (cascade.kaba.or.jp [202.249.19.34]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iB83UqAd009413; Wed, 8 Dec 2004 04:30:54 +0100 Received: from localhost (ferengi.kaba.or.jp [202.249.19.16]) by mail.kaba.or.jp (Postfix) with ESMTP id A0C9349AAA; Wed, 8 Dec 2004 12:30:51 +0900 (JST) Date: Wed, 08 Dec 2004 12:30:51 +0900 (JST) Message-Id: <20041208.123051.74739504.keiko@kaba.or.jp> To: damien.doligez@inria.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Type constraints From: nakata keiko In-Reply-To: <41B62407.4020102@inria.fr> References: <41B5F1B2.3000503@inria.fr> <9296F5C2-4893-11D9-8195-000D9345235C@inria.fr> <41B62407.4020102@inria.fr> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41B6756F.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41B6756C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 kaba:01 damien:01 wrote:01 struct:01 struct:01 ...:98 ...:98 polymorphic:01 polymorphic:01 doligez:01 expression:01 syntactic:01 syntactic:01 typing:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: Damien Doligez wrote: >The typing algorithm is very simple (really!): > >1. Type the module. Generalization occurs and the v field gets a > polymorphic type. >2. Type "M.v". This takes an instance of the polymorphic type. >3. Can we generalize it? Look at the syntactic shape of the expression > (in this case, let module ... in ...). If it is always safe to > generalize such expressions, OK. If not, do not generalize. > >That's the beauty of the Wright criterion: it's very easy to implement >and to understand (because it is syntactic), and works well in almost >all >cases (with a little eta-expansion if needed). This does not answer to me why this works, #type t = { t : 'a. 'a -> 'a} #let v = let module M = struct let t x = x end in {t = M.t} in (v.t 5, v.t true) Of cource, both of the following are not type checked, #let v = let module M = struct let t = x end in M.t in (v 5, v true) #let v : 'a -> 'a = let module M = struct let t x = x end in M.t in (v 5, v true) However, if I can write something like #let v : 'a. 'a -> 'a = let module M = struct let t x = x end in M.t in (v 5, v true) then, it would be type checked ? Regards, Keiko.