Re: [Caml-list] Array.filter (was Multi-keyed lookup table?)

[Ville-Pertti Keinonen <will@exomi.com>]

On Sun, Aug 10, 2003 at 10:43:19PM +0200, Michal Moskal wrote:

> It will bomb for large arrays. List.filter will not (BTW I don't
> understand why List.filter uses List.rev to be tail recursive and List.map
> does not).
> 
> Another thought would be to create bool array for predicate results, fill
> it, counting how much space do you need, and then create result array.
> 
> There is also third way, to run predicate twice, but it is not guaranteed
> safe in presence of side effects.

How about just creating a result array the same size as the original
(initially filled with item 0 of the original, special-cased for
empty arrays) and Array.sub:ing it for the result?  I'd think that
would be the obvious method.  Creating new instances of a value
shouldn't have any noticable side-effects.

Anyway, filter for arrays as well as strings is one of the more
useful things that might be desirable as part of the standard
library.  Functions for mapping and folding strings might also be
useful.  While the OCaml standard library is pretty good, it seems
fairly sparse compared to e.g. the functionality offered by Common
Lisp sequence functions, which work on lists, arrays and strings.

Implementing the necessary functionality is easy, but an advantage
of having more things as part of the standard lirbary would be the
reduction in LOC for OCaml solutions to programming tasks used to
compare programming languages (e.g. Prechelt's study, although that
didn't include OCaml).  OCaml isn't otherwise much more verbose
than Common Lisp (ignoring macros) or various scripting languages,
but for array and string manipulation, it can end up looking much
worse than it needs to.

Plenty of people who don't know many languages seem to believe that
static typing and/or explicit lexical scoping inevitably make
languages verbose, and that dynamically typed scripting languages
with idiosyncratic scoping rules and huge performance hits are the
only way around that.

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