Browse thread
[Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jon Harrop <jon@j...> |
| Subject: | Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features |
On Saturday 25 September 2004 23:52, Vasili Galchin wrote:
> I am reluctantly learning C++ STL (Standard Template Library) and the
> notion of templates. Templates don't seem to be that great ... just
> parametric plymorphism done in a somewhat heavy handed way when compared to
> the same in OCaml, Haskell, etc.
A beneficial (although inelegant) advantage of templates is the ability to
partially specialise programs by performing arbitrary compile-time
computation. This is not available in OCaml. This will be addressed (in a
much more powerful and elegant way) by MetaOCaml just as soon as Taha at al.
stop reading this mailing list and start working harder. ;-)
> However, teh STL notion of containers and
> available operations allowed on containers does seem to be be very powerful
> and not available in OCaml. Is the last statement true?
That last statement is only true in the absence of higher-order functions.
Therefore, it does not apply to OCaml.
In functional languages, like OCaml, the operations on containers are much
more productively factored into higher-order functions which are then
container-type independent. In particular, the ubiquitous map and fold
functions.
For example, to sum the floating-point elements of a container in C++, one
might write:
#include <iostream>
#include <list>
#include <vector>
template<typename IT>
double sum(IT begin, IT end)
{
double ans=0.;
for (IT it=begin; it!=end; it++)
ans +. *it;
return ans;
}
int main(void)
{
list<double> A;
A.push_back(0.);
A.push_back(1.);
A.push_back(2.);
A.push_back(3.);
A.push_back(4.);
vector<double> B;
B.push_back(0.);
B.push_back(1.);
B.push_back(2.);
B.push_back(3.);
B.push_back(4.);
cout << sum(A.begin(), A.end()) << endl
<< sum(B.begin(), B.end()) << endl;
}
The OCaml equivalent would be:
let sum fold_left c = fold_left ( +. ) 0. c
sum List.fold_left [0.; 1.; 2.; 3.; 4.]
sum Array.fold_left [|0.; 1.; 2.; 3.; 4.|]
If you have more time than sense then you'll prefer the C++ version (which is
vastly more verbose and a bit quicker). If, on the other hand, you can see
the forest for the trees then you'll want to be using OCaml because, given
the same time, you can write OCaml programs which are both faster and smaller
than equivalents written in virtually any other language. Not to mention that
compilation of equivalent programs is typically between one and two orders of
magnitude faster using ocamlopt rather than g++.
Believe it or not, the previous example favours C++ more than most others.
Check out this example of function composition from SGI's STL manual:
list<int>::iterator new_end =
remove_if(L.begin(), L.end(),
compose2(logical_and<bool>(),
bind2nd(greater<int>(), 100),
bind2nd(less<int>(), 1000)));
L.erase(new_end, L.end());
In OCaml:
let l = List.filter (fun x -> not (100<x<1000)) l
These days, when I read fancy statements in the STL manual, like "function
object adaptor", I just roll around laughing.
The STL does have some contructs which do not have direct equivalents in
OCaml. Type traits, for example, allow templates to carry information on
concrete types such that more highly type-specialised functions can be used
to perform a given task, chosen at compile time. However, OCaml errs on the
side of run-time polymorphism rather than compile-time.
Cheers,
Jon.
PS: I made several errors when writing that C++ code. Even if you just put
"A()" instead of "A" when declaring a list, you get a page full of STL
errors. God its nice to be writing OCaml... :-)
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners