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 GAA27427; Fri, 29 Jun 2001 06:18:40 +0200 (MET DST) 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 GAA27436 for ; Fri, 29 Jun 2001 06:18:38 +0200 (MET DST) 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 f5T4Ib517455; Fri, 29 Jun 2001 06:18:37 +0200 (MET DST) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f5T4I4R36212; Fri, 29 Jun 2001 00:18:06 -0400 (EDT) (envelope-from patrick@watson.org) Date: Fri, 29 Jun 2001 00:18:04 -0400 (EDT) From: Patrick M Doane To: John Max Skaller cc: Jun Furuse , caml-list@inria.fr Subject: Re: "Re: [Caml-list] A G'Caml question" + additional info In-Reply-To: <3B3BB6EC.3DEB6CBF@ozemail.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 29 Jun 2001, John Max Skaller wrote: > Patrick M Doane wrote: > > > > We do not want to introduce the full open recursion to generic > > > values. You could add new type cases easily using the open recursion > > > and it should be helpful in some cases. But it can also introduce > > > heavy semantic confusion to our programs, since in the open recursion > > > the semantics of generic values could not be fixed until all modules > > > are linked together. > > > > I agree that this could make programs more difficult to follow, but I > > think it is to be expected with generic programming these days. > > Yes, its expected: which is very good reason NOT to do it. > Its expected that all the problems associated with it have to exist, > because people haven't seen anything better. I would like to apply the generic programming techniques so that I can have reusable algorithms. The extensions provided by GCaml don't achieve that goal although they are much more powerful than basic operator overloading. If I want to define a generic function similar to the STL for_each function, this works fine until I need to extend the system with new iterator types. The proposed 'include' feature makes it much easier to extend generic values, but doesn't help with derived generics. I would assume that most folks are interested in the reusability of those derived generics. Does it make sense to provide a similar construct to 'include' for derived generics which would re-analyze the body of the code based on a new context of generic values? Or am I trying to abuse what these features are intended for? Maybe this kind of approach is better suited to the object system or using functors. Patrick ------------------- 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