Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: William Lovas <wlovas@s...>
Subject: Re: [Caml-list] productivity improvement
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