Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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