]> On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote: > However, the C++ version looks more "extensible" to me: Suppose that in a > while, you decide that you want your "node" to be not only Leaf or Unop or > Binop, but also Triop: > > type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a * 'a -> > 'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node * 'a node * > 'a node;; > > You will need to modify the original node type and function "eval" by adding > an extra pattern to "match" statement, and then recompile everying that > depends on it. At the same time, with C++ the type of node remains the same. > You just need to derive a new class from it: > > [snip] > > Recompiling isn't necessary. In fact, "old code" may call "new code" if you > happen to pass it a node that happens to be a triop. Yes, but what if you decide to add a new function on nodes? Like say, typecheck, or eval2, with slightly different semantics? In the O'Caml version, it's as simple as that -- add a new function and run with it. With the C++ version, though, now you have to modify *every* *single* *class* that inherits from node, and recompile them all. So it really seems that it's just a question of what's most important for your own particular purpose. Someone looking to extend the definition of node indefinitely would prefer an object-oriented version, while someone focused on providing new functionality over nodes would prefer the functional version. > Oleg > > P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly > book, and having gotten some experience with O'Caml, I'm running low on > motivation right now. Please give me examples of what's > hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have > only finite time, so 50 KLOC Coq is not a good example :) It strikes me that although you were able to quite easily translate this toy evaluator example into C++, this may not have been the case with a larger, more complex example. It's something that scales exponentially, so you're probably not going to find very many small, concise examples that show conclusively how much easier O'Caml is. (And, of course, you have to take into account the style question mentioned above. One style does not necessarily fit all.) William ------------------- 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