On Wednesday 28 April 2004 4:15 pm, John Goerzen wrote:
> On Wed, Apr 28, 2004 at 06:13:19AM +0100, Jon Harrop wrote:
> > The main thing is that it is iterator-centric, so you pass iterators
> > around instead of containers. For example, to represent a subarray
> > without having to copy it. These iterators are classified according to
> > their abilities (e.g.
>
> That's not necessarily a good thing.  For one, it leads to complexity.

Absolutely, incidental complexity at that.

> What if you modify the parent array?  Would the iterator show the new or
> original values?

New values. The iterator presents a view of the original data. For example, 
you might have a function which normalises a vector which is passed to it as 
a pair of iterators. You could then use this function to normalise a column 
vector in a matrix by passing it "stride" iterators which transparently 
return a single element from each row (i.e. a column) instead of adjacent 
elements.

> What if you truncate the parent?  Would the iterator
> produce fewer results than it originally promised?

No, your program would crash. Possibly corrupting the file system. ;-)

> And of course, you
> can't so nicely use iterators in match clauses like you can lists.

Yes, exactly.

I think the "control driven" STL propaganda is just marketing hype. IMHO, such 
approaches to algorithmics are only justified as an inadequate work-around 
for the absence of higher-order functions. Look for "bind2nd" in the STL, for 
example.

Cheers,
Jon.

-------------------
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