I've often wondered why languages don't support "extensions" to library
namespaces (and perhaps even to functors).  e.g. one could define 

let String.explode s = ....
let String.implode s = ...
let myfun = ...

If you like you can consider this as a shorthand for the longwinded
declaration of a module and the rebinding of member names.  Since all the
typing mechanisms are "monotonic" w.r.t. adding new members to a module
(i.e. if a module matched a signature before it will continue to match after
an addition like the above) then this should make sense theoretically.   The
implementation can probably just whack in another element to the dictionary
structure that represents a module.  

The "signature" of a seperately compilation unit would probably have to
declare how the unit extends existing structures, functors and signatures,
e.g. the .mli for the above code might be: 

val String.explode : string -> char list
val String.implode : char list -> string
val myfun : int -> int

I put "signature" in quotes because the extensions are not part of signature
of the module defined by the unit itself (i.e. the rule "each compilation
unit introduces one new top level module" would be relaxed.

You then probably need a distinction between "open" and "load", i.e. open a
top level module namespace and load a compilation unit, and you probably
need to explicitly load any compilation units that define extensions (rather
than relying on the default behaviour of OCaml where a compilation unit is
"loaded" by virtue of using a module access, e.g. Myfile.myfun).  For
example:

(A) open Myfile  (* myfun now in scope *)

(B) load Myfile  (* String.explode, String.implode, Myfun.myfun now in
scope. *)
    open Myfile  (* myfile becomes available *)

(B) Myfile.myfile (* OK - but String.explode not available without an *)
                  (* explicit load *)

I think that with that distinction in place dependency analysis would be OK.
More ambitiously, perhaps one could even extend functors coherently in this
way, i.e. 

let Set.Make(Ord: OrderedType).set_exists = ...

Realistically you probably need a way of accessing the existing elements
generated by the application, which we could do by reusing my favourite
keyword "as".... e.g

let (Set.Make(Ord: OrderedType) as M).set_exists = ...
    try M.fold (fun x _ -> if p x then failwith "t") s (); false
    with Failure "t" -> true

This is all quite similar to the mechanisms I used for the module mechanism
in my theorem prover "Declare", which didn't have functors as such, but even
the basic mechanisms certainly did make the abstract algebra examples I did
look quite nice.

Don

P.S. I don't know if you could also add types to modules in this way?



-----Original Message-----
From: Jerome Vouillon [mailto:Jerome.Vouillon@inria.fr]
Sent: 13 March 2000 09:26
To: caml-redistribution@pauillac.inria.fr
Subject: Re: additions to standard library?


On Tue, Mar 07, 2000 at 04:24:00PM +0100, Markus Mottl wrote:
> What do you think about the idea to make use of the "usercontrib"
> CVS-repository at INRIA for such purposes? We could open a "stable" and
> "development" branch for standard libraries (and "otherlibs") there, where
> people could place and "peer review" their contributions. From time to
> time, the OCaml-team can peek at the additions and take what they consider
> useful.

I see two dangers:
- this could result in an over-featured library;
- the "regular" and the "extended" library may diverge.
On the other hand, I don't think it would be a bad thing if more
people contributed to the development of O'Caml.

Anyway, you can always set up a repository on Sourceforge or any
similar site and see what happens. :-)

-- Jérôme