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 GAA08820; Thu, 28 Jun 2001 06:40:59 +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 GAA09116 for ; Thu, 28 Jun 2001 06:40:59 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f5S4esD01327 for ; Thu, 28 Jun 2001 06:40:58 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id VAA20495; Wed, 27 Jun 2001 21:40:43 -0700 (PDT) Date: Wed, 27 Jun 2001 21:40:43 -0700 (PDT) From: Brian Rogoff To: Patrick M Doane cc: caml-list@inria.fr Subject: Re: "Re: [Caml-list] A G'Caml question" + additional info In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 27 Jun 2001, Patrick M Doane wrote: > On Mon, 25 Jun 2001, Jun Furuse 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. > Also, isn't this kind of semantic confusion already present with using the > object oriented system? > > In the following example, writing definitions like MyProgram.print may get > very tedious in practice. > > module Int = struct > generic print = case int -> unit => print_int > end > > module String = struct > generic print = case string -> unit => print_string > end > > module List = struct > generic print = > case $a list -> unit => function [] -> () | x :: xs -> print x; print xs > end > > module MyProgram = struct > generic print = case > | include Int.print > | include String.print > | include List.print > (* all other print functions to follow *) > end Actually, that doesn't look too bad to me. Once generics play well with modules and functors (and classes and polymorphic variants :), support the include syntax Jun described, and are in the release (along with a safer marshaling) I'll be very pleased The real issue which open recursion would solve is if you had, say, a recursive generic for printing lists recursively, one for doing arrays recursively, and one for doing tuples (up to some fixed arity). Here's how you'd write it now generic print_basic = case | int -> unit => print_int | float -> unit => print_float | char -> unit => print_char | string -> unit => print_string | bool -> unit => (function true -> print_string "true" | _ -> print_string "false") generic rec print_seq = case (* print_tuple *) | $a * $b -> unit => fun (u,v) -> print_seq u; print_seq v | $a * $b * $c -> unit => fun (u,v,w) -> print_seq u; print_seq v; print_seq w | $a * $b * $c * $d -> unit => fun (u,v,w,x) -> (print_seq u; print_seq v; print_seq w;print_seq x) | $a * $b * $c * $d * $e -> unit => fun (u,v,w,x,y) -> (print_seq u; print_seq v; print_seq w;print_seq x;print_seq y) (* print_array *) | $a array -> unit => fun a -> Array.iter print_seq a (* print_list *) | $a list -> unit => fun l -> List.iter print_seq l | $a -> unit => print_basic;; note that this can print a lot of stuff because of recursion: # print_seq (1,2);; 12- : unit = () # print_seq (1,(2,(3,(4,(5,(6,(7,(8,9))))))));; 123456789- : unit = () # print_seq (1,[|(2,3);(4,5);(6,7)|],"8",9.0);; 123456789- : unit = () but you can't break it into parts print_tuple, print_list, print_array and construct print_seq by composing them. Oh well, they still give a much needed overloading and have lots of power to spare. > Given what is done with Haskell type classes and C++ templates, it seems > more confusing to me to not support open recursion. Any thoughts? They're really powerful. Once the design and implementation are more stable, we'll see how important the lack of open recursion is. I think it's more important to have human understandable error messages and inferred types. I'm already looking forward to the merger with OCaml proper. -- Brian ------------------- 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