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 27212BC75 for ; Wed, 16 Feb 2005 07:41:41 +0100 (CET) Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j1G6fdlW002920 for ; Wed, 16 Feb 2005 07:41:40 +0100 Received: from localhost (millas [172.16.30.29]) by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id j1G6fYLf026132; Wed, 16 Feb 2005 15:41:34 +0900 (JST) Date: Wed, 16 Feb 2005 15:40:22 +0900 (JST) Message-Id: <20050216.154022.71085981.garrigue@math.nagoya-u.ac.jp> To: dubochet@urbanet.ch Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Polymorphic variant typing From: Jacques Garrigue In-Reply-To: <86796353528dde143b07545f7e94ed17@urbanet.ch> References: <7bf1f3b95c18eeda0ed169eb7f73d6f0@urbanet.ch> <20050216.093635.226803934.garrigue@math.nagoya-u.ac.jp> <86796353528dde143b07545f7e94ed17@urbanet.ch> X-Mailer: Mew version 4.0.69 on Emacs 21.3.50 / 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 4212EB23.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 algebra:01 ocaml:01 remy's:01 avoiding:01 o'caml:01 model:01 verbose:01 variants:01 polymorphism:01 crystal:98 ...:98 polymorphic:01 abstract: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: Gilles Dubochet > > The main reason for this choice is avoiding making rows explicit, > > i.e. having a multi-sorted type algebra. Note also that ocaml object > > types, while originally based on Remy's system, are hiding their > > row-variables, and can be described in the same formalism. > Just to make it crystal clear for me: You say that the "main reason for > this choice is avoiding making rows explicit", does this mean that the > O'Caml team feels that row-based type information is too complicated > for an average user since you either steer away of hide it in an object > model? Basically yes. Hence the clever tricks to have types containing hidden row variables, like #t, [< t], [> t]. Having explicit row variables was considered at some point, but it was not done because types would become much more verbose. Consider for instance that with variants, presence/absence information is needed for each tag. On the other hand, advanced features like explicit polymorphism require some understanding of the presence of hidden variables, and how they interact, so at that level of proficiency it's not clear whether hiding them really helps. And I'm now playing with abstract rows, which makes the decision even less clear... Jacques Garrigue