On 11/24/05, Richard Jones <rich@annexia.org> wrote:
> (1) What is the point of having two rev functions?  Arrays are indexed, you
> can just access n-i instead of i.

I'm not sure if the objection is to having 'Array.rev*' altogether or
having two different versions of this function.  Well, the point of
having 'Array.rev' is simply because there is a 'List.rev'.  'Array.-
rev_in_place' is an extension to the standard set of common functions
which only applies to the special case of arrays because arrays are

Both ;)  But, I see some other languages seem to have library functions for in place reversal.  Still, though, I'm unconvinced that there should be a copying reversal function.  In the C++ STL, they defined interface functions to be general across container types.  List doesn't have this property: it was designed to be an interface for List alone.  And List is an immutable container type.  So, I think we should be careful about duping the behaviour of List here.

> (2) find_all should return a list.  e.g. find_all in ExtHashtbl returns a
> list.

OK, but conversely List.find_all is defined as identical to
List.filter.  Hashtbl.find_all is quite a different function.  It
returns all values associated with a single key, and only makes sense
because of a peculiarity of Hashtbl, namely that one can associate
multiple values with a key.

True.  But I already stated another, probably more important reason above: filter suggests it returns the same container type as it was given.  find_all doesn't suggest this at all.  They are the same in list only because (barring enums) the only sensible return type for find_all is a list.

Maybe we should change the documentation of ExtList.find_all to make this clear.  i.e. say, find_all returns a list containing matching elements, in the case lists, it is equivalent to filter.