Re: [Caml-list] stl?

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 04 March 2009 00:58:59 Yoann Padioleau wrote:
> Jon Harrop <jon@ffconsultancy.com> 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<int>, 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