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 CBD9EBC48 for ; Thu, 31 Mar 2005 10:32:49 +0200 (CEST) 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 j2V8Wnj0015509 for ; Thu, 31 Mar 2005 10:32:49 +0200 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 KAA26757 for ; Thu, 31 Mar 2005 10:32:48 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2V8Wkvh015500 for ; Thu, 31 Mar 2005 10:32:47 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j2V8WX7W026625; Thu, 31 Mar 2005 17:32:33 +0900 (JST) Date: Thu, 31 Mar 2005 17:32:23 +0900 (JST) Message-Id: <20050331.173223.128566586.garrigue@math.nagoya-u.ac.jp> To: yminsky@cs.cornell.edu, yminsky@gmail.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] When is a function polymorphic? From: Jacques Garrigue In-Reply-To: <891bd33905033020045cad3ce2@mail.gmail.com> References: <891bd339050330165142478f37@mail.gmail.com> <20050331.114253.48852731.garrigue@math.nagoya-u.ac.jp> <891bd33905033020045cad3ce2@mail.gmail.com> 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 nez-perce with ID 424BB5B1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 424BB5AE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 yaron:01 minsky:01 yminsky:01 avoided:01 predictable:01 variants:01 constructors:01 polymorphic:01 polymorphic:01 jacques:01 jacques:01 checking:01 checking:01 algorithm:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: From: Yaron Minsky > Interesting. I guess this is best understood as a limitation of the > type-checking algorithm. Does anyone know if there are any plans to > remove this limitation? Are there fundamental reasons why it would be > difficult to do so? This is not a limitation of the type checking algorithm per se. Rather, the type checking algorithm prefers not to use exhaustiveness information when this can be avoided, to keep it predictable. (Exhaustiveness is only used for polymorphic variants, but for a deeper reason.) Is it so difficult to make the extra constructors explicit? Jacques Garrigue