Re: [Ocaml-lib-devel] Enum module

[Nicolas C. <war...@fr...>]

> A question and a comment:
>
> 1) There are several data structures already extant that should have
> enum_of functions for- strings, arrays, lists, hash tables, sets, maps,
> stacks, queues, and buffers.  So, where do we put these functions?  In the
> enum package, or do we fork all 8 standard libraries just to add a single
> function?

Actually, we are already planning to add new functions to String, Array,
List, HashTable so theses are not causing any problem.
Ok now let's talk about the current namespace design I have setuped :

There is two ways of using the ExtLib :
1) as a library of new functions, without overridding the ocaml stdlib ones
:
        open ExtLib

        let f = ExtList.to_enum (* from ExtList *)
        let f = List.hd (* from ocaml stdlib *)

2) as on overring of the ocaml stdlib ones :
        open ExtList

        let f = List.to_enum (* from ExtList *)
        let f = List.hd (* from ExtList *)

This is quite good, since if people wants to add for example support for
tail-rec calls, they only have to add an "open ExtList" at the beginning of
the code, but if people only wants new functions in an different namespaces,
then they will have to link with all ocaml stdlib overriding modules - which
are not so big - since there is not yet "pack as cma".

Okay, now for ExtList we have (thanks to Brian) a full implementation of the
module List.
But are we sure we want the same for others modules ? Shouldn't we only
provide new functions without overridding all the module ?
Theses questions are of course only for the few modules of the ocaml stdlib.
The ExtLib "new" modules such as Global, RefList, BitArray, Vector :) and
so... will cause no problem.

> Personally, I think psqueue and xarray and bitarray should have enum_of
> and of_enum functions in their code.  I don't want to be updating enum
> every time I add a new data structure.  On the other hand, forking 8
> libraries just to add 2 functions each strikes me as being a little
> extreme.

Of course ! You'll see on the CVS that I have add the *enum* functions to
ExtList, but I didn't put any of theses in the Enum.

> 2) I dislike having the same function both return the current element and
> increment to the next element.  First off, this can cause bugs, as
> unexpected next's moves you forward.  These bugs are probably less like in
> Ocaml than in Java or C++ (in C++, mixing next calls with macros was a
> recipe for disaster), due to the habit of throwing let ... in clauses
> freely, but they can still happen.  Second, this allows you to do act like
> you have an ungetc- you simply don't call the increment function until you
> know you're done with the current element.
>
> Maybe two different functions- current, which returns whatever the last
> call to next returns, and next (same as now).  Calling current before
> calling next throws an exception.  You could advance the pointer simply by
> going:
>     let _ = next enum in ();
> Or maybe a third function, advance.

If you look at enum.mli, there is NO WAY of doing a next() !
Why ? because most of the time ( 99.99999% ) , you want to apply the same
algorithm to all the elements of your data structure, and I have the Java
while( e.hasMoreElements() ) { Object o = e.nextElement(); ... }. The "next"
function has to be implemented by the data structure, so the user won't know
about it, and the data structure of_enum implementation itself will have to
use most of the time Enum.fold/iter to fill itself.

Users are :
- getting enum's from differents data structures
- making lazy operations on them ( such as map , filter )
then to "run" the enumeration, they have only few choices :
- call the of_enum of a data structure
- use iter, fold, or find, who are actually returning a result

Nicolas Cannasse