additions to standard library?

additions to standard library?

[Markus Mottl]

Hello,

it sometimes happens that I need functions on abstract data types in the
standard library which are not available there, but could be considered as
"usual" operations on such data. Also some other very commonly useful
functions could be added.

I was just wondering which way would be best to propose additions to the
standard libraries - I have modified a few standard modules, which now
contain additional functionality that might be useful for others, too.  Is
it a good idea to send patches against the standard library in the hope
that they might be integrated?

Some specific examples include, e.g.:

  * Char: functions like is_upper, is_lower, is_alpha, is_...

  * Set: functions like for_all, exists, filter (find_all), partition.

         These functions are in "List", too, but actually fit perfectly
         to sets.

  * Stack: with function top

           Currently, the only way to use "Stack" in such a way is to
           pop an element and push it again...

  * String: the functions explode and implode for conversions of char
            lists to strings and vice versa.

            Especially useful for teaching, because it allows students to
            use a functional style of programming when implementing string
            algorithms.

There are some other additions, too, which I haven't yet fully integrated
into standard library modules.

Other people surely also have proposals for further additions to the
libraries. I can imagine that the OCaml-development team does not have the
time to deal with all such suggestions.

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.

This approach might be appealing to both sides:

  * the OCaml-team can decide when to integrate what and won't get a bad
    conscience by having to "bin" user suggestions.  Additionally, some
    "boring" development work can be delegated to the user community (I
    know that developing compilers is more interesting than writing
    standard libraries... ;-)

  * the user community finally has a means to express their wishes in a
    more direct way - which might increase the probability that suggestions
    really get considered.

What do the developers and other users think of this idea?

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: additions to standard library?

[Jean-Christophe Filliatre]

In his message of Tue March 7, 2000, Markus Mottl writes: 
> it sometimes happens that I need functions on abstract data types in the
> standard library which are not available there, but could be considered as
> "usual" operations on such data. Also some other very commonly useful
> functions could be added.

I agree. 

One may think  that the functions you suggest  can actually be defined
outside  the  standard library  using  iterators  like  fold (not  for
Stack.top, however). For instance, one can define set_exists as

======================================================================
# module Myset = Set.Make(struct type t = ... let compare = ... end);;
...
# let set_exists p s =                                             
    try Myset.fold (fun x _ -> if p x then failwith "t") s (); false
    with Failure "t" -> true;;                                     
val set_exists : (Myset.elt -> bool) -> Myset.t -> bool = <fun>
======================================================================

But  when  using functorial  interfaces  like  Set.Make,  you have  to
redefine these  functions for each  application of the  functor. Thus,
you  really need these  functions to  be defined  in the  functor i.e.
together with the datatype (and, by the way, you can then define these
functions a bit more efficiently---without using exceptions).

-- 
Jean-Christophe Filliatre    
  Computer Science Laboratory   Phone (650) 859-5173
  SRI International             FAX   (650) 859-2844
  333 Ravenswood Ave.           email  filliatr@csl.sri.com
  Menlo Park, CA 94025, USA     web    http://www.csl.sri.com/~filliatr

  

Re: additions to standard library?

[Markus Mottl]

> But  when  using functorial  interfaces  like  Set.Make,  you have  to
> redefine these  functions for each  application of the  functor. Thus,
> you  really need these  functions to  be defined  in the  functor i.e.
> together with the datatype (and, by the way, you can then define these
> functions a bit more efficiently---without using exceptions).

Exactly - this raises another question which has been bothering me from
time to time when using the module system:

How can you extend the functionality of a module without having to "copy"
the definitions of the underlying module "by hand"? In a case which I found
particularly ugly (in the "res"-library), I had to "copy" nearly 100 lines
as in:

  module Foo = struct
    module B = ...
    type t = B.t
    ...
    let iter = B.iter
    let iteri = B.iteri
    let map = B.map
    let mapi = B.mapi
    ...
  end

Everytime the other module gets extended, I have to add code by hand here,
too, to make it available. I do not see any simple workaround for this.
Extending standard libraries with needed functionality would be much easier
if there were a convenient way to get around the problem above.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: additions to standard library?

[Christian RINDERKNECHT]

On Wed, Mar 08, 2000 at 11:29:30PM +0100, Markus Mottl wrote:
>
> [...] another question [...] has been bothering me from
> time to time when using the module system: 
> [...] I had to "copy" nearly 100 lines as in:
> 
>   module Foo = struct
>     module B = ...
>     type t = B.t
>     ...
>     let iter = B.iter
>     let iteri = B.iteri
>     ...
>   end

..and don't forget the lack of exception re-binding that moreover
requires a lot of "try with": "try B.iter with B.Exc -> raise Exc"...

-- 

Christian

-----------------------------------------------------------------------
Christian Rinderknecht                     Phone +33 (0)1 60 76 44 43
Institut National des Télécommunications   Fax   +33 (0)1 60 76 47 11
Département Logiciels Réseaux (LOR)        WWW
9, Rue Charles Fourier, F-91011 Évry Cedex

additions to standard library?

[Thorsten Ohl]

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.

> CVS-repository [...] "peer review"

That's a brilliant idea!

Here's another issue in the same problem domain, that might be more
interesting for developers: wouldn't it be possible to add a language
feature that allows to extend module implementations without opening
the pandora box of classes with inheritance?

Currently, we can use `include' to extend module types, but not
implementations.  I'm thinking of something like

    module type ThoList =
      sig
    	include List  (* doesn't work because list.mli is a file,
                         but you get the idea :-) *)
    	val flatmap : ('a -> 'b list) -> 'a list -> 'b list
      end
    
    module ThoList : ThoList=
      sig
    	include List
    	let rec flatmap f = function
    	  | [] -> []
    	  | x :: rest -> f x @ flatmap f rest
      end
 
Cheers,
-Thorsten
-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]

Re: additions to standard library?

[Francisco Valverde Albacete]

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

Re: additions to standard library?

[Markus Mottl]

> 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.

I also think that it is a sensible strategy of INRIA to keep the interfaces
of their libraries uncluttered. An "experimental" repository for libraries,
where people can work out possible additions cooperatively, would be a very
appealing project. I would also be prepared to volunteer in such an effort.

Xavier once posted the following mail:

  http://pauillac.inria.fr/caml/caml-list/1087.html

Is it still possible to get CVS-accounts at INRIA? It would also be
possible to use "http://sourceforge.net", but I have no experience in
setting up projects there nor whether there might be any objections to
doing such a project on a host outside the control of INRIA - maybe John
Skaller, who uses it for his Python-compiler, can tell us more about it?

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: additions to standard library?

[Max Skaller]

Markus Mottl wrote:

> Is it still possible to get CVS-accounts at INRIA? It would also be
> possible to use "http://sourceforge.net", but I have no experience in
> setting up projects there nor whether there might be any objections to
> doing such a project on a host outside the control of INRIA - maybe John
> Skaller, who uses it for his Python-compiler, can tell us more about it?

I'm no expert, but sourceforge.org seems pretty good. The thing
I think I will find a bit clumbsy is the way releases are built,
but I haven't made one yet. 

As for cooperative development, it may be an excellent idea
to have a sourceforge based ocaml library so that ocaml
users can help each other (and the ocaml implementors).
This is much better than each person 'doing their own thing',
or 'hassling' the implementors.

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: additions to standard library?

[Brian Rogoff]

On Fri, 10 Mar 2000, Francisco Valverde Albacete wrote:
> 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).

>From what I understand, this is what classes and objects are for, though
of course in OCaml there aren't yet polymorphic methods so you lose a lot 
in trying to write extensible ADTs in OCaml this way. If we had
polymorphic methods would that tip the balance in favor of classes for a
utility library? 

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

I bet a lot of the penalty of OO style could be eliminated if you have a 
compiler that does lots of global analysis, like the SmallEiffel 
compiler. 

> 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.

That's too bad, I think that some kind of macro approach might be useful
for this problem.

-- Brian

Re: additions to standard library?

[Jerome Vouillon]

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

Re: additions to standard library?

[Pierre Weis]

> It is also not my intention to get over-featured libraries. I was just
> wondering which would be the best way to propose reasonable additions
> and/or contribute code. I am not out for a specific way to do this - I just
> would like to know which way would be most appropriate for INRIA. It would
> be disappointing for both sides if unwise decisions in this respect lead to
> something like "diverging development".
> 
> At the moment I have the feeling that some modules are indeed rather
> under-featured. One can really not say that e.g. the "Char"-module boasts
> with rich features, and some others (like the mentioned Set-module) would
> also not suffer if functions like "partition" or "for_all", etc., are
> added, especially considering the fact that these "settish" functions even
> exist in the List-module.

You're right: for the time being our libraries are in some sense
minimalist (due to the ancient times problems with memory capacities
of micro computers and 1.4 Mb floppies). It may be time now to get
reasonably featured libraries. For instance, you mentioned few
functions that sound adequate to be added (in the first place because
there are not a zillion of them).

> > On the other hand, I don't think it would be a bad thing if more
> > people contributed to the development of O'Caml.
> 
> Definitely! Though, there should be some standard way to contribute so that
> people don't step on each other's toes. Naturally, the opinion of the main
> developers should set the direction...
> 
> > Anyway, you can always set up a repository on Sourceforge or any
> > similar site and see what happens. :-)
> 
> I have thought about this, but I am not sure whether this provokes what you
> mentioned: that the "regular" and the "extended" library diverge. On the
> other hand, it seems that Sourceforge really provides for great features
> for free software projects (CVS-repository, mailing lists, bug tracking,
> patch manager, etc...), which would reduce at least the administrative
> effort on INRIA's side...

We also have the tools you mentioned to develop the Caml compiler
(``CVS-repository, mailing lists, bug tracking, patch manager,
etc...''), except may be ``etc...'':), so that there is no need to set
up another site to develop the Caml standard library (on the other
hand the use of SourceForge may be very relevant for other
cooperative developments out of the Caml compiler). In any means we
must avoid confusion and divergence with 2 different standard libraries.

Caml users may contribute to the wish list associated to the caml bugs
tracking system: you may contribute in a useful way if you also
provide the code associated to your wishes.

Best regards,

-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis

RE: additions to standard library?

[Manuel Fahndrich]

The issue you are raising is a good one. SML/NJ can handle some of it,
because the semantics of "open" are different there. Once can actually say:

	module Foo = struct
        open B
      end

and obtain a copy of B within Foo.

This might even work to extend functors as in:

	functor Foo(Arg : A) =
        struct
           module B = Bar(A)
           open B
           let extensions = ...
        end


However, this interpretation of "open" has impacts on compilation
dependencies, in particular scoping analysis (See e.g.  "Dependency analysis
for Standard ML; Matthias Blume; ACM Trans. Program. Lang. Syst. 21, 4 (Jul.
1999), Pages 790 - 812").

-Manuel



-----Original Message-----
From: Markus Mottl [mailto:mottl@miss.wu-wien.ac.at]
Sent: Friday, March 10, 2000 12:04 AM
To: caml-redistribution@pauillac.inria.fr
Cc: caml-list@inria.fr
Subject: Re: additions to standard library?


> But  when  using functorial  interfaces  like  Set.Make,  you have  to
> redefine these  functions for each  application of the  functor. Thus,
> you  really need these  functions to  be defined  in the  functor i.e.
> together with the datatype (and, by the way, you can then define these
> functions a bit more efficiently---without using exceptions).

Exactly - this raises another question which has been bothering me from
time to time when using the module system:

How can you extend the functionality of a module without having to "copy"
the definitions of the underlying module "by hand"? In a case which I found
particularly ugly (in the "res"-library), I had to "copy" nearly 100 lines
as in:

  module Foo = struct
    module B = ...
    type t = B.t
    ...
    let iter = B.iter
    let iteri = B.iteri
    let map = B.map
    let mapi = B.mapi
    ...
  end

Everytime the other module gets extended, I have to add code by hand here,
too, to make it available. I do not see any simple workaround for this.
Extending standard libraries with needed functionality would be much easier
if there were a convenient way to get around the problem above.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

RE: additions to standard library?

[Don Syme]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3723 bytes --]


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

Re: additions to standard library?

[John Max Skaller]

Don Syme wrote:
> 
> 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 = ...

The reason is that it is hard to localise these changes.
It isn't acceptable to extend the actual module, since two clients
could provide conflicting "extensions". This would break the
Open/Closed principle [Meyer, OOSC]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

RE: additions to standard library?

[Don Syme]

> > 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 = ...
> 
> The reason is that it is hard to localise these changes.
> It isn't acceptable to extend the actual module, since two clients
> could provide conflicting "extensions". This would break the
> Open/Closed principle [Meyer, OOSC]

With regard to conflicts, I don't see that taking a strict approach is
particularly wonderful.  Scoping and locality are, of course, important, and
of course you still have to be able to know exactly the signatures you are
compiling against (i.e. the sum of all the extensions you've imported).
Conflicts can be detected whenever you try to combine extensions (compile
time or link time) - of course conflicts can occur, but that doesn't mean
the facility is not very useful when they do not.  Effectively the same
problem occurs when you do this "module List2 = struct include List ... end"
nonsense, with the horrible proliferation of modules and extensions that
result, and nightmarish management of extensions.  Even in this setting
there's no way around the potential for conflicts, but, if you assume they
aren't going to occur (e.g. because of some agreed project management of a
namespace), then what's the best way forward?  I think optimistic is better
than pessimistic: make the most pleasant system to use, assuming conflicts
won't occur, but if they do give errors at compile time.

[ I also think you could implement it so that only conflicts at compile time
(rather than link time) were significant, by qualifying names in generated
code according to their compilation units. This gives you quite a high
degree of locality, and even if conflicts occur between two extensions
you're using, you can choose, by restricting one signature or another
appropriately, which parts of which extension you want to make use of.  Or
something like that.  ]

With regard to open/closed, in ML, the signature mechanism provides the way
to close structures and restrict access.  Thus I don't think allowing
clients to extend the underlying _structures_ contravenes this.  I wouldn't
want to be able to extend _signatures_ that other clients rely upon, unless
they see and explicitly make use of my extension.  And the extender would
not receive any special rights to access aspects of the structure hidden
from me.

Thus, for example, you could still implement an abstract data type and
restrict access globally via a signature.  No one could mess with your data
type by extending your module, because no one has the privileges necessay to
access the underlying representation.  However they could augment your
module with their own stuff, which could be very, very useful, as the Set
functor example indicates.

In an OO setting, particularly with overriding, the question may be
different, but that's not quite what we're talking about here.  However,
even Java binary compatibility, for example, specifies ways in which the
classes you run against may be "richer" than the ones you compiled against.
The question is just one of who gets to extend, what rights they have, and
how this maps onto the namespace facility of a language.

Cheers!
Don

-----Original Message-----
From: John Max Skaller [mailto:skaller@maxtal.com.au]
Sent: 21 March 2000 21:08
To: Don Syme
Cc: 'caml-list@inria.fr'
Subject: Re: additions to standard library?


Don Syme wrote:
> 
> 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 = ...

The reason is that it is hard to localise these changes.
It isn't acceptable to extend the actual module, since two clients
could provide conflicting "extensions". This would break the
Open/Closed principle [Meyer, OOSC]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net