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=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 156A1BC6B for ; Fri, 22 Jun 2007 02:33:23 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5M0XLhY028006 for ; Fri, 22 Jun 2007 02:33:23 +0200 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id l5M0XA6Q014086; Fri, 22 Jun 2007 09:33:11 +0900 (JST) Date: Fri, 22 Jun 2007 09:32:56 +0900 (JST) Message-Id: <20070622.093256.102578198.garrigue@math.nagoya-u.ac.jp> To: julien.signoles@cea.fr Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] generalization and let module From: Jacques Garrigue In-Reply-To: <1182439513.19841.88.camel@localhost> References: <1182439513.19841.88.camel@localhost> X-Mailer: Mew version 4.2 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 concorde with ID 467B18D1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; signoles:01 signoles:01 struct:01 struct:01 functor:01 polymorphic:01 cea:01 caml-list:01 structures:02 garrigue:03 garrigue:03 module:03 module:03 jacques:03 jacques:03 From: Julien SIGNOLES > Just a single question: why is 'f' not generalizable in the following > example? I'm not able to find an example using any "let module" and > breaking the type safety. > > ===== > module M = struct end > let f = let module N = M in fun x -> x > ===== What about let f = let module M = struct let x = ref [] end in fun x -> let y = List.hd !M.x in M.x := [x]; y ;; Making this function polymorphic would clearly be unsound. However, you're right on one account: this can only happen with structures, but not with module aliasing, or even functor application. So the non-expansiveness check could be refined. Jacques Garrigue