From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA12459 for caml-redistribution@pauillac.inria.fr; Wed, 22 Mar 2000 17:02:57 +0100 (MET) Resent-Message-Id: <200003221602.RAA12459@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA27947 for ; Tue, 21 Mar 2000 22:43:40 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id WAA10580 for ; Tue, 21 Mar 2000 22:43:39 +0100 (MET) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Mar 2000 13:43:28 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Tue, 21 Mar 2000 13:43:27 -0800 Message-ID: <39ADCF833E74D111A2D700805F1951EF1801452B@RED-MSG-06> From: Don Syme To: "'John Max Skaller'" Cc: "'caml-list@inria.fr'" Subject: RE: additions to standard library? Date: Tue, 21 Mar 2000 13:43:18 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Resent-From: weis@pauillac.inria.fr Resent-Date: Wed, 22 Mar 2000 17:02:57 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > > 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