Re: additions to standard library?

["Francisco Valverde Albacete" <fva@tsc.uc3m.es>]

Hi, Ocamlers,

There follows a rather lengthy mail on this subject, (all in English I am
afraid: I could not make my French stretch to try to make fine points...), so
be warned!

Thorsten Ohl wrote:

> Markus Mottl <mottl@miss.wu-wien.ac.at> writes:
>
> > Hello, it sometimes happens that I need functions on abstract data
>             ^^^^^^^^^ often :-)
> > types in the standard library which are not available there, but
> > could be considered as "usual" operations on such data.
>
> > Some specific examples include, e.g.:
>
> My favorites are Map and List, of which I keep carrying around
> turbocharged versions.

Yes... I've done the coding of functional iterators on some dozen ADT
(written as functors or modules) by now. At first I pretended that they would
not be necessary but in the end I found I had to code them all, (with all the
fuss added of making them visible in the signatures of the implementations,
etc).

PRO: For this reason I've developed a method of writing ADTs incrementally
meaning that I can add some related primitives at a time, i.e. all iterators
on containers, all constructors for sequences, some extended iterators, etc.

CON: This exacted a lot of design on a hierarchy of signatures that could be
refined by the use of the "include" feature which is a rather coarse method
of establishing a semantic hierarchy, but unfortunately the only one
available at present.

CON: But this same procedure of refinement is not available for
implementations by the lack of a feature similar to "include" for modules in
Ocaml. I know some languages have it (OBJxx or something similar) and some
language "proposals" too... But in Ocaml we have to make to with repeating
definitions.

PRO: The good thing as X. Leroy stated some time ago is that we do not incur
in any penalty for such definitions.

CON: The bad thing is that the type specialization of functions through this
method is disallowed from some versions of the compiler onwards. For example,
you have to use:

let new_particular_map func some_data =
    (old_polymorphic_map func some_data : mono_type2 container)

instead of

let new_particular_map = (old_polymorphic_map :
    (mono_type1 -> mono_type) -> mono_type1 container -> mono_type2
container)

CON: Thus you really create another closure on top of the polymorphic one,
thus increasing running time. (I don't remember exactly if the problem
manifests itself this way... I've learnt to avoid this second style of coding
and seldom get the compilation error nowadays.)

My proposal for now (not the most elegant, I know) would be to add a
syntactic feature in the language similar to "include" for signatures, but
effecting textual inclusion of module code, as T.Ohl suggests. Some time ago
I thought this could be managed by using Camlp4, the caml preprocessor, but
then the implementor suggested it was hardly used except for Coq and I was
loath to tackle with it.

The *real thing* would be to have a real nice (semantic) inheritance
mechanism for modules but this does not go well with separate compilation,
does it (uh, actually this is a question for the implementor team)? The
impression I got from a good set of slides by X. Leroy I got my hands on
talking about the differences between classes and modules was, that it was
under study in the community but still hazy... Issat so?


> > CVS-repository [...] "peer review"
>
> That's a brilliant idea!

Yes. Definitely... Maybe there is a point in keeping the standard library
uncluttered and supply a parallell library based on the standard one but
giving more functionality... This way, the implementor team can concentrate
efforts in the compilers and environment and the concerned users can keep a
"utility" library up-to-date... I'd be more than willing to contribute code &
work to such an effort.

        Fran Valverde
        Dpto. Tecnologías de las Comunicaciones
        Universidad Carlos III de Madrid, Spain