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.2 required=5.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.1.3 Received: by yquem.inria.fr (Postfix, from userid 24253) id 4A327BC6D; Wed, 14 Nov 2007 15:35:24 +0100 (CET) Date: Wed, 14 Nov 2007 15:35:24 +0100 To: Alain Frisch Cc: Pierre Weis , caml-list Subject: Re: [Caml-list] Compiler feature - useful or not? Message-ID: <20071114143524.GA4423@yquem.inria.fr> References: <473A363F.2080301@gmail.com> <891bd3390711131608g48b584a4n6b0ccab95d7de3f3@mail.gmail.com> <20071114075827.GA24058@yquem.inria.fr> <473AEC04.3030303@frisch.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473AEC04.3030303@frisch.fr> User-Agent: Mutt/1.5.9i From: weis@yquem.inria.fr (Pierre Weis) X-Spam: no; 0.00; compiler:01 weis:01 weis:01 abbreviation:01 abbreviation:01 compilation:01 compiler:01 invariants:01 abstraction:01 low-level:01 low-level:01 type-based:01 integers:01 compilation:01 type-based:01 Hi Alain, > Pierre Weis wrote: > >type row = private int;; > > The only difference with an abstract type is that a private type is not an abstract type but a concrete type. > 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 don't understand what you mean by ``exporting a private type abbreviation is useless''. In fact, you cannot create a private abbreviation if you do not `export'' it and define it as private when exporting, isn't it ? (Clearly, if you define a private type abbreviation in an implementation file, this definition is completely useless since you cannot define any value of the private type). However, if I interpret what you said as: ``if we only want to optimize the compilation, there is no point to define a private type instead of an abstract type in the case of a complex type abbreviation'' then the question is somewhat equivalent to ask ``in which case the compiler can optimize when faced to a type abbreviation ?'': the answer is complex but in particular the compiler can optimize a type t defined as being a (concrete) abbreviation for a float array or a (concrete) abbreviation for a record of floats. In any case, the purpose of introducing private abbreviation type definitions is not to optimize programs but to write clearer and safer programs. In particular because private data types can ensure invariants the same way as abstract data types do; and also because private data types support pattern matching the same way as concrete types do. Once more, private abbreviation types being concrete, they get all the advantages of concrete types and all their drawbacks (in particular wrt abstraction of value representation, evolution of implementation programs, openness of algorithms, meta informations). > I find it somewhat disturbing to expose low-level optimization features > as part of the type system. No low-level optimization is ``exposed in the type system'': the low level (type-based) optimizations are just an automatic side effect of a private data type being indeed a concrete type. In other words, would you say that you ``expose low level optimization as part of the type system'' if you ever define a vector as being a float array instead of being a M.t array value with M.t being an abstract abbreviation for float ? In some cases, the answer can be yes: you may need to ``unabstract'' types for the sake of efficiency. But generally speaking, you just use the type float because it is the type of values you need, the optimizations come then from the compiler as a very welcome bonus. > 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.) That's another story: the problem with this approach is to prevent breaking the separate compilation feature of the actual compiler. In any case, private type abbreviations have been implemented as a new useful tool for the programmer, not as a way to optimize programs. Type-based compiler's optimizations are just an extra plus, I thought it was worth to mention that private type abbreviations are fully compatible with these optimizations. But in the first place, private type abbreviations are useful to define proper concrete sub types of another type. All the best, -- Pierre