Re: [Caml-list] stl?

From: Yoann Padioleau <padator@wanadoo.fr>
To: "Mikkel Fahnøe Jørgensen" <mikkel@dvide.com>
Cc: Raoul Duke <raould@gmail.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] stl?
Date: Wed, 04 Mar 2009 10:48:18 -0600	[thread overview]
Message-ID: <87eixdz12l.fsf@aryx.cs.uiuc.edu> (raw)
In-Reply-To: <caee5ad80903040835g3ad76a39n72bbc39476bc9d03@mail.gmail.com> ("Mikkel =?utf-8?Q?Fahn=C3=B8e_J=C3=B8rgensen=22's?= message of "Wed\, 4 Mar 2009 17\:35\:56 +0100")

Mikkel Fahnøe Jørgensen <mikkel@dvide.com> writes:

> 2009/3/3 Raoul Duke <raould@gmail.com>:
>> hi,
>>
>> the caml archives show discussion around C++ polymorphism wrt STL
>> (since Stepanov iirc said that C++ was the only language which
>> supported what he needed to let him implement his generic programming)
>> but i didn't yet see anywhere a concrete implementation or mapping
>> from C++ STL to O'Caml.
>
> As I recall, Stepanov did originally work containers in Lisp or
> similar, but realized this would never help "real world" programmers.
> The C++ template is far more powerful than originally anticipated and
> Stepanov took advantage of that. Clearly, the choice of C++ has
> affected the design of STL, so it would be pointless to try to port
> STL directly to OCaml.
>
> In fact, I think that OCamls basic Array, List, containers and
> polymorphic algorithms  does exactly what Stepanov intended to do,

I don't think so. I've read the last "history of C++" by Stroustrup
in HOPL-III, who discusses quite a lot about the STL and Stepanov,
and from what I remember unboxing was a big issue
and having "generic" (which is slightly different from polymorphic)
algorithms without introducing performance
penalty that object-solution has with dynamic dispatch was also
a big issue. Those people are not stupid. They know about ML.
C++ even has some advanced dependent types in some way (array<n>).

I hate C++ with a passion, but the C++ designers are far from stupid.

> without having to introduce Functors or other overhead. However, OCaml
> could do with a more precisely defined container duck typing interface
> (not an interface just convention) which I think will happen with
> Batteries. I think perhaps OCaml could have a library of algorithms
> that are not specific to one container type, but again that requires
> better duck typed containers, and perhaps it is just better and more
> efficient to implement the most important operations for each
> container type instead of trying to generalized the entire world.
>
> Scripting languages were not so hot at the time, short of Perl, but
> Ruby would easily fit well into the STL idea, just like Lisp also did.

No, because of the performance penalty of dispatch. Again, those C++
designer guys have strong requirments on performance. Most
of us can live with those overheads, but apparently they don't.

> There was a discussion by STL insiders about wether algorithms (simple
> example is the min function) should be template parameterized. They
> ended up not having explicit type arguments because this was much
> simpler to work with. Containers (like vector) have type arguments
> because they were necessary in C++.
>
> As to whether STL is well designed or not, fast or not, I think STL at
> the time solved a great problem. Of course you could do something
> faster, but often a map or set would be just what needed, just like
> OCamls current Map and Set is usually good enough.

Sure (when they are defunctorized ... :) )

>
> Mikkel
>
> _______________________________________________
> 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