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 33C6FBC6B for ; Wed, 11 Jul 2007 04:23:24 +0200 (CEST) Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6B2NM7R026914 for ; Wed, 11 Jul 2007 04:23:23 +0200 Received: from localhost (rabbit-172 [172.16.254.254]) by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id l6B2N7BJ027909; Wed, 11 Jul 2007 11:23:07 +0900 (JST) Date: Wed, 11 Jul 2007 11:23:07 +0900 (JST) Message-Id: <20070711.112307.2004150273.garrigue@math.nagoya-u.ac.jp> To: jon@ffconsultancy.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] large parametrized polymorphic variant type combinations take forever to compile From: Jacques GARRIGUE In-Reply-To: <200707110219.35727.jon@ffconsultancy.com> References: <46938BDA.1090605@podval.org> <20070711.091002.39162301.garrigue@math.nagoya-u.ac.jp> <200707110219.35727.jon@ffconsultancy.com> X-Mailer: Mew version 4.2 on Emacs 21.4 / 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 46943F1A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; parametrized:01 constructors:01 hash:01 hash:01 variants:01 variants:01 datatypes:01 trivial:01 compilation:01 polymorphic:01 polymorphic:01 compile:01 compile:01 caml-list:01 constructor:01 From: Jon Harrop > Isn't it a really bad idea to autogenerate polymorphic variant type > constructors anyway because, sooner or later, you'll get a hash clash? In > fact, wouldn't that be platform specific? Indeed, a hash clash can happen. It will be detected at compile time, but in a generated setting it may be harder to fix. Fortunately, at least this is not platform specific: the hash function for variants is defined only once and for all. Also, it is explicitly defined so that names of up to 4 characters will all get different hash values. On the other hand, as the intent of polymorphic variants is to be able to use understandable constructor names, rather than complex imbrications of datatypes, a large part of their interest is lost here. > I would recommend factoring the sum type by the argument types of the > contructors in this case. Looking at Sam's files, this is trivial. Just > replace this: [..] > with this: > > type t1 = [ > | `t1_int of [ > | `a > | `a0 > | `a10000 ] * int > | `t1_float of [`b] * float > ] This is mostly a matter of taste, but this might help producing better code, independently of the compilation time. Of course, one can also think of types that you cannot decompose this way, if the type of the argument is always different for instance. Jacques Garrigue