From: Nicolas C. <war...@fr...> - 2003-05-27 06:58:02
|
> > Even if I like Streams I think that enums are somehow much powerful and less > > error prone (since you can't do next() ). > > The more I think about this, the more I disagree. Case in point: consider > taking a list of items and turning it into a balanced tree. Using the > standard list operations, this is not too horribly ugly: > > > type 'a tree_t = Void > | Node of 'a tree_t * 'a * 'a tree_t Errr... I didn't think about recursive structures. It's true that having Enum.next() would be here very better. So ok let's add : val next : 'a Enum.t -> 'a option (updated CVS) > Now consider rewritting this to take an Enum instead of a list. You have > to force the algorithm into fold somehow- which means managing a > handrolled stack (the above code is double non-tail recursive). Since you're building a tree you don't need to be tail rec ( the stack will grow in O(log n) ! ) > For sheer code clarity, I think 'a option is a cleaner response than > throwing an exception. I don't agree here : - the new "exported" next is returning 'a option and that's a good thing ( no need to catch exception, code is more clear ) - BUT the internal next is most of the time "concatening" the next functions in a purely functional way, so for example after two Enum.maps and doing an Enum.iter, you'll have to check the None/Some three times ! Raising an exception which propagate to the upper level is really a better choice. - this choice is only making the code a little harder for the Enum modules, other modules will never have to catch No_more_elements. I think this is a good compromise. Nicolas Cannasse |