RE: additions to standard library?

[Don Syme <dsyme@microsoft.com>]

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