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.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id BDB34BC69 for ; Wed, 14 Nov 2007 13:37:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH96OkfB/BYdlmdsb2JhbACPAAEBBwQGIgc X-IronPort-AV: E=Sophos;i="4.21,416,1188770400"; d="scan'208";a="4439590" Received: from smtp20.orange.fr ([193.252.22.29]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 13:37:33 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2014.orange.fr (SMTP Server) with ESMTP id BA90E1C000AB for ; Wed, 14 Nov 2007 13:37:32 +0100 (CET) Received: from [192.168.1.59] (APuteaux-154-1-12-161.w83-199.abo.wanadoo.fr [83.199.69.161]) by mwinf2014.orange.fr (SMTP Server) with ESMTP id 90C7E1C000A0; Wed, 14 Nov 2007 13:37:32 +0100 (CET) X-ME-UUID: 20071114123732593.90C7E1C000A0@mwinf2014.orange.fr Message-ID: <473AEC04.3030303@frisch.fr> Date: Wed, 14 Nov 2007 13:37:24 +0100 From: Alain Frisch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pierre Weis Cc: caml-list Subject: Re: [Caml-list] Compiler feature - useful or not? References: <473A363F.2080301@gmail.com> <891bd3390711131608g48b584a4n6b0ccab95d7de3f3@mail.gmail.com> <20071114075827.GA24058@yquem.inria.fr> In-Reply-To: <20071114075827.GA24058@yquem.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 compiler:01 weis:01 abbreviation:01 low-level:01 integers:01 compilation:01 compiler:01 disturbing:98 equality:01 wrote:01 abstract:01 abstract:01 caml-list:01 Pierre Weis wrote: > type row = private int;; The only difference with an abstract type is that some generic operations (comparision, equality) can be optimized, and currently, it happens only for some basic types. So exporting a private abbreviation (instead of an abstract type) is useless when the type is not a basic type. Is it correct? I find it somewhat disturbing to expose low-level optimization features as part of the type system. Couldn't a similar thing (specializing operations on integers) be achieved by always storing manifest types in .cmxs files? (Within a single compilation unit, the compiler could keep type definitions across module boundaries.) Alain