Re: additions to standard library?

From: Francisco Valverde Albacete (fva@tsc.uc3m.es)
Date: Fri Mar 10 2000 - 11:04:05 MET

  • Next message: Christian RINDERKNECHT: "Re: additions to standard library?"

    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



    This archive was generated by hypermail 2b29 : Fri Mar 10 2000 - 19:50:57 MET