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.3 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 98DDFBBC4 for ; Wed, 4 Mar 2009 02:24:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEBAABnrUnUnwckjmdsb2JhbACCHZJqAQEBAQkLCAkPBsFFhAgG X-IronPort-AV: E=Sophos;i="4.38,297,1233529200"; d="scan'208";a="25019519" Received: from relay.ptn-ipout02.plus.net ([212.159.7.36]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Mar 2009 02:24:02 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EAABnrUnUnw6S/2dsb2JhbACCHdRthAgG Received: from ptb-relay02.plus.net ([212.159.14.146]) by relay.ptn-ipout02.plus.net with ESMTP; 04 Mar 2009 01:24:01 +0000 Received: from [87.112.234.120] (helo=leper.local) by ptb-relay02.plus.net with esmtp (Exim) id 1Lefq5-00005u-FB for caml-list@yquem.inria.fr; Wed, 04 Mar 2009 01:24:01 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Date: Wed, 4 Mar 2009 01:29:23 +0000 User-Agent: KMail/1.9.9 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903032336.53089.jon@ffconsultancy.com> <87vdqqyugc.fsf@aryx.cs.uiuc.edu> In-Reply-To: <87vdqqyugc.fsf@aryx.cs.uiuc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903040129.23236.jon@ffconsultancy.com> X-Plusnet-Relay: 2d84d35078ca96a84d939792d2d9bb3d X-Spam: no; 0.00; stl:01 stepanov:01 unboxed:01 ocaml:01 'int:01 integers:01 ocaml:01 variants:01 unboxed:01 indirections:01 functor:01 functors:01 functors:01 functorize:01 monads:01 On Wednesday 04 March 2009 00:58:59 Yoann Padioleau wrote: > Jon Harrop writes: > > On Tuesday 03 March 2009 22:31:55 Yoann Padioleau wrote: > >> I don't know what are the Stepanov requirements, but C++ > >> can do unboxed collections like list, which OCaml can > >> not provide I think. a 'int list' has boxed integers in OCaml. > > > > The currently OCaml implementation never boxes ints and the boxing of > > other types (like float) is an artefact of the current implementation not > > found in other language implementations like F# and my HLVM. Moreover, > > this is not even a visible difference. > > Oh, Ok. Is it true for other types such as list of records, > list of variants, list of pairs, etc ? In the current OCaml implementation, yes, but not in F# and my HLVM where all such types are stored unboxed. That not only removes indirections but it also drastically reduces the number of allocated blocks that the GC has to work with and, therefore, places a lot less stress on the GC. > > OCaml can do that too. Just wrap your code in a functor and parameterize > > it > > The interesting word in your sentence is "just". The big problem with > functors is that it's never a "just". Functors are too intrusive. If > you have somewhere a function that needs to use this 'find', then you > will be forced to functorize the whole caller chain, including other > modules. That's really really really intrusive. It's exactly why > monads in haskell are mostly a bad idea. They are too intrusive. Yes. People often call that "creep" and I agree that it can be a PITA during development when you do not have a clear idea of what should and should not go into the functor. > Imagine if the 'list' type would be in a functor and instead of > 'a list you would have a List: functor(T). Each time you have > a function using a list you would need to put it inside a functor... > In fact this happens for OCaml data-types such as Set or Map which > is why most people have defined their own defunctorized Set or Map > that just use Pervasive.(=). That is a really bad workaround for a flaw in the language which, again, is fixed in both F# and HLVM through the introduction of per-type functions for printing, equality, comparison, serialization and so on. > That does not mean Functors or monads are completely a bad idea, they > have their use (I used them sometimes), but they have lots > of drawbacks. Trade-offs. Type inference is the flip side of that coin. Overloading like "find" in C++ destroys type inference and that makes for really horrific code. You see that a lot when using F# with the .NET libraries. OCaml is a thing of beauty here. Polymorphic variants make it even nicer and, of course, that is another feature than Haskell does not have... > > The STL is extremely slow. If you want fast code in C++ then you drop to > > the C subset. Alex Stepanov tried and failed to implement efficient > > constructs in the STL. Furthermore, the memory consumption of his library > > is awful. OCaml's GC is far more efficient with memory whilst permitting > > easy sharing. > > I agree. Java is also better than C++ in that respect because > it also leverages sharing. Yes. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e