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=1.6 required=5.0 tests=AWL,DNS_FROM_RFC_POST 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 7F0C8BBC4 for ; Wed, 4 Mar 2009 01:59:16 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBACNhrUmArgVgkWdsb2JhbACCHYpMiB8BAQEBCQsKBxEEwVgHhAEG X-IronPort-AV: E=Sophos;i="4.38,297,1233529200"; d="scan'208";a="25018705" Received: from expredir5.cites.uiuc.edu ([128.174.5.96]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2009 01:59:15 +0100 Received: from axyr (aryx.cs.uiuc.edu [128.174.236.106]) by expredir5.cites.uiuc.edu (8.14.2/8.14.2) with ESMTP id n240xAgQ026201; Tue, 3 Mar 2009 18:59:11 -0600 (CST) To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <87zlg2z19g.fsf@aryx.cs.uiuc.edu> <200903032336.53089.jon@ffconsultancy.com> From: Yoann Padioleau Date: Tue, 03 Mar 2009 18:58:59 -0600 In-Reply-To: <200903032336.53089.jon@ffconsultancy.com> (Jon Harrop's message of "Tue\, 3 Mar 2009 23\:36\:52 +0000") Message-ID: <87vdqqyugc.fsf@aryx.cs.uiuc.edu> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam: no; 0.00; stl:01 stepanov:01 unboxed:01 ocaml:01 'int:01 integers:01 ocaml:01 variants:01 stl:01 arrays:01 hash:01 iterator:01 functor:01 functors:01 functors:01 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 ? > >> Also, a maybe good thing with STL is that you can write a single 'find' >> or 'sort' function that will work for every kind of collections >> (list, arrays, map, hash, etc) by using the >> indirect iterator idiom, without the penalty of dynamic dispatch >> solutions. I am not sure OCaml can do that too. > > 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. If in haskell you have a deep nested function that needs to do some IO, then you need to "monadize" the whole call chain which is just painful. 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 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. > over the module implementing the data structure (e.g. List or Array). Modules > and functors are second-class statically resolved constructs in OCaml so > there is no dynamic dispatch. > >> The question is do we really need those 2 things? > > Parameterizing code using functors is extremely useful but it goes far beyond > the usable capabilities of C++. I think the next C++ has a 'concept' mechanism quite similar to haskell typeclasse. But as usual with C++, it's wrapped in a ugly syntax way, will have awful error messages, and that will probably makes it impossible in practice to be used by mere mortals. >> I've worked a little bit with C++ using unboxed objects, that >> is without introducing pointers (similar to boxing) in templates, >> like list
instead of list, and passing them >> as value in parameters, or returning them, >> and it was far less efficient because there was lots of copy, >> and you could not use then virtual method on them. So in the >> end the C++ programmer I thing manually re-introduce boxing >> when using STL if he wants good performance, and he can not really >> rely either on the default copy/equal implementation provided >> by those templates. So, yes STL makes it possible to do things, >> but programmers don't want them, or only in very few cases where >> one need extreme performance. > > 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. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs