From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA22918; Fri, 9 Nov 2001 19:15:32 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA16305 for ; Fri, 9 Nov 2001 19:15:30 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA9IFT514493 for ; Fri, 9 Nov 2001 19:15:30 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.6/8.11.5) with ESMTP id fA9IFAN84373; Fri, 9 Nov 2001 13:15:15 -0500 (EST) (envelope-from patrick@watson.org) Date: Fri, 9 Nov 2001 13:15:09 -0500 (EST) From: Patrick M Doane To: Eric Newhuis cc: Caml Subject: Re: [Caml-list] Dynamic vs. Static In-Reply-To: <003001c1693c$6c1e3dc0$d0c201cf@XENO> Message-ID: <20011109130158.O80907-100000@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk The compelling argument to me in this paper is the example regarding collections and Java. The type for the method public boolean AbstractCollection::removeAll(Collection c) is obviously too restrictive. The argument in favor of it was to reduce the number of interfaces in the standard library. There is good reason for limiting this in Java because subtyping is directly related to inheritance. To introduce a new interface would require figuring out how to compose all of these pieces together. Caml doesn't suffer from this particular problem because subtyping is not related to inheritance. It would be trivial to create a new class type that is used in various type signatures that specify exactly the set of methods that are required. C++ templates have a similar kind of freedom in that the types in that the types needed to compile a function are inferred directly from the definition of that function. The problem with a system like C++ and also with the dynamic approach (as far as I know - please correct me if this is wrong) is that there are times when it is useful to constrain a type by more than what is required for a particular implementation. I've seen several cases of STL container objects in C++ that work for one implementation of the standard algorithms but fail to work with a different implementation. Now the author had made a mistake with respect to the documentation, although everything was legal from the compiler's viewpoint. It's also worth noting that, for whatever reason, Caml does not have a very good collection library. The modules indivually are quite good but they lack the unification that allows a developer to easily plug in a new implementation as needed. Patrick On Fri, 9 Nov 2001, Eric Newhuis wrote: > Would anyone care to read this and comment on it w.r.t. Caml/ML/etc? > > http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing+Message > > ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr