From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E43FBBBBB for ; Mon, 28 Nov 2005 08:49:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jAS7nC5g016101 for ; Mon, 28 Nov 2005 08:49:12 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA09196 for ; Mon, 28 Nov 2005 08:49:11 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jAS7n93g016094 for ; Mon, 28 Nov 2005 08:49:10 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id jAS7n4x3025354; Mon, 28 Nov 2005 16:49:04 +0900 (JST) Date: Mon, 28 Nov 2005 16:49:00 +0900 (JST) Message-Id: <20051128.164900.41199864.garrigue@math.nagoya-u.ac.jp> To: david.baelde@ens-lyon.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Efficency of varient types From: Jacques Garrigue In-Reply-To: <53c655920511272324w1630fe89y@mail.gmail.com> References: <53c655920511272324w1630fe89y@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 concorde with ID 438AB678.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 438AB675.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 variants:01 variants:01 runtime:01 integers:01 compiler:01 integers:01 polymorphic:01 polymorphic:01 short:01 int:01 int:01 jacques:01 jacques:01 variant:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: David Baelde > First, I'd like to point that you're talking about sum types and not > variants. For short, variants are the backquoted labels `Int of int, > and I think they cost more at runtime, for they cannot be encoded as > integers. Unfortunately there is no such clear distinction: sum types are also often called variant types (inside the compiler too), and polymorphic variants can be abbreviated as "variants". Some people even call the latter "open sum types", to make things even muddier. More importantly, polymorphic variants are internally encoded as integers, so there is no representation cost for constant tags. Polymorphic variants with value arguments take extra space, as they put the variant tag in an extra field, and cannot be optimized for the multi-argument case, but we are then talking of cases where allocation is required anyway. Jacques Garrigue