Re: [Ocaml-lib-devel] candidate functions

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

> > > I'd prefer ExtLib.List.int
> > >
> > > That way, I can switch from StdLib.List to ExtLib.List by just
> > > "opening" ExtLib in my sources.
> >
> > This way, you're supposing that ExtLib.List will be a reimplementation
of
> > the List module... I don't that's the purpose here. Let's just say that
>
> More than a reimplementation, I see it as a superset.
>
> ExtLib would pass through without change most StdLib functions, add a few
> missing functions and shadow the bad guys in StdLib (incorrect functions
> in List and so)
>
> It may also add a few sub-modules missing in StdLib, and maybe a few
> functions missing in Pervasives. So, "open ExtLib" will give you an
> enhanced OCaml environment.

I would actually like to have that, but :
- I don't really agree when you're qualifying "bad guys" some stdlib
functions. and I don't think that the caml team will agree also :)
- the only "bad guys" for me are the functions which are raising either
Invalid_argument or Failure when users are supposed catch it to handle (for
example, creating an Array with a negative size is a good "invalid_argument"
raise case, while List.hd is not )
- we can't modify theses functions without giving them a different name (
for obvious stdlib compatibily reasons ) but when can provide different
implementations ( such as stoi & stof in the ExtLib.String proposed in v0.1
as alternatives to int_of_string & float_of_string )

The last point is about compilation and module linkage.
If you want to do "open ExtLib" and then "open List" for exemple, then
ExtLib have to be ONE big module (perhaps several files linked together with
the -pack option, but still one big cmo ) and so will always be entirely
linked with your bytecode if you're using only one function of it... so
that'll prevent us from adding new modules since each time it will get
bigger and bigger. If you have another structure/compilation proposal....

Regards,
Nicolas Cannasse