On 11/24/05, Richard Jones <firstname.lastname@example.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
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.