This is a good thread in my opinion, I think it is worthwhile to understand the differences. I have only worked with SML and scheme, but not ocaml but I wanted to give a few humble additional points that are related.

One thing about choosing your tool for a solution is the maintainability. From my experience on a very large project with C++ and java code, the maintainability is very good because they have taken the time to introduce templated design patterns in just the right places to make common activities (object creation -- the factory pattern) and persistence easier to manage for folks who are trying to fix bugs. In my case we are working with financial use cases -- you don't really want to have an obfuscated block of code in front of you that takes advantage of closures or lazy evaluation for cases that are high-traffic in making transactions. What C++ allows you to do in this case that a more purely functional language does not is having a close proximity to english in explaining what is happening. A small example:

bool AnalyzeReferenceSpending(MoneyTransaction trans)
{
ReferenceChain refChain = trans.GetReferenceChain();

int totalRefSpending;
int totalRefAvailable;
for (iterator on refChain obj)
{
totalRefSpending += (*iterator).GetSpent();
totalRefAvailable += (*iterator).GetAvailable();
}
if (trans + (totalRefSpending - totalRefAvailable) > 0 )
return true;
else
return false;
}

This is a contrived example but it does illustrate the style of transaction processing that we have in financial applications. When you have someone coming in to make a change to this function, you want it to be CLEAR what is going on. Not only that, but in this case we also have a clear parallel between the written code and what is being executed at the machine level -- you could write this in assembly in about 5 minutes if you have some practice at doing that.

OCAML could be fine to write financial transactions, sure. But it is not just about making it run fast and being smart enough to be sneaky without being sneaky. This code above is simple... it's meant to be simple, and not ever get any more complicated.

I personally think that SML and its ilk are very powerful and well-suited to a certain class of problems. I am interested in how they wrote a ray-tracer in it, but I think maintenance is one of the most important aspects of the software development cycle. Additionally, the first step, design, can also be more costly if you are working in a functional language because you have to be more careful. All the best,

Jeremy

Quote:Original post by SamLowry
Since I love surprises:

**code snipped**

let fst pair () =  let (x, _) = pair ()  in  x ();;let snd pair () =  let (_, y) = pair ()  in  y ();;

should be

let fst pair () =  let (x, _) = pair ()  in  x;;let snd pair () =  let (_, y) = pair ()  in  y;;

I don't think pair is lazy since it always evaluates both of it's contents. Not sure if that's important though.

Quote:Original post by SamLowry
It's actually not a big surprise, I had already noticed that Haskell/ML/OCaml looked a lot like Lisp without the outer parentheses. But then again, wasn't ML based on the typed lambda calculus with some syntactic sugar on top? It's Lisp's statically typed twin in a way.

Statically checked, yes. Don't forget pattern redundancy/exhaustion checking etc.

Here's my OCaml equivalent:

let rec eval = function    `Lit i -> `Int i  | `Inc e -> (match eval e with `Int i -> `Int (i+1) | _ -> invalid_arg "int")  | `IsZ e -> `Int (if eval e = `Int 0 then 0 else -1)  | `If(p, t, f) -> eval(if eval p <> `Int 0 then t else f)  | `Pai(a, b) -> `Pai(eval a, eval b)  | `Fst e -> (match eval e with `Pai(x, _) -> x | _ -> invalid_arg "fst")  | `Snd e -> (match eval e with `Pai(_, x) -> x | _ -> invalid_arg "snd");;eval(`Pai(`IsZ(`Lit 0), `If(`IsZ(`Inc(`Lit 10)), `Lit 1337, `Lit 999)));;

What's wrong with this?

Cheers,
Jon.

Quote:Original post by phantom
I got bored and decided to make the C++ code more concise;

That's much better, thank you.

Quote:

list<int> &haar(list<int> &s, list<int> &d, list<int> &l) {	if (s.empty() && l.size() == 1) return d.push_front(l.front()),d;	if (l.empty()) return haar(l, d, s);	list<int>::iterator i = l.begin(), j = i++;	s.push_front((*j)+(*i)), d.push_front((*j)-(*i)), l.erase(j,++i);	return haar(s, d, l);}

ok, so I took advantage of a couple of tricks there (operator , for example), but I'm not a C++ expert by any means, as such a competent C++ coder should be able to understand that code as well and its about 2 lines longer than the O'Caml version (infact, if you were to move that return statement up a line and tack ',haar(s,d,l)' onto the end then its only one line longer due to the '}').

The test code is longer, but even that can be simply shortend;

int _tmain(int argc, _TCHAR* argv[]) {	int data [] = {1,2,3,4,-4,-3,-2,-1};	list<int> l(data,data+8);	list<int> l2=haar(list<int>(), list<int>(), l);

You've taken references to two temporaries here. Tut tut.

Quote:

	copy(l2.begin(), l2.end(), ostream_iterator<int>(cout, " "));	cout << endl;	return 0;}

no real point to this, as I said, I was bored and trying to put off doing an assignment [grin]

You're right, fst and snd were defined incorrectly.

Updated version:


And I have to admit that pair is indeed not fully lazy, but at least it's coherent with the C++ version :)

# let p = pair (lit 0) (lit 1);;(* When evaluating p, I expect (0, 1) *)# p ();;(0, 1)

However

# let p = pair (lit 0) (never_ending_computation);;# fst p ();;(* no answer, while it should give 0 *)

I don't see how I could (elegantly) make pair properly lazy without changing the entire design. I should be able to send messages (OOP-like, as described in SICP), I'll try it out.

EDIT: lazy version

Ugly. Also, could someone explain to me why I need to explicitly state the type of the argument "pair" in fst and snd? If I don't, O'Caml assumes msg is not optional and complains about pair being a "?msg:pair_message -> unit -> 'a * 'b" while it expects a "msg:pair_message -> unit -> 'a * 'b".

Quote:Original post by jdh30
You've taken references to two temporaries here. Tut tut.

hmmm, you raise a good point there... I wonder if I've wandered into 'undefined' areas of the C++ map... infact, now I consider it, I'm slight amazed it works as I'm returning a reference to a tempory from the function... *chuckles* thats what you call not paying attension.. but VC++8 seems to let it work just fine...