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 WAA28110; Sat, 30 Nov 2002 22:47:51 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA29727 for ; Sat, 30 Nov 2002 22:47:50 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gAULlCX09381; Sat, 30 Nov 2002 22:47:12 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA29551; Sat, 30 Nov 2002 22:47:11 +0100 (MET) From: Pierre Weis Message-Id: <200211302147.WAA29551@pauillac.inria.fr> Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading. In-Reply-To: from Mike Lin at "Nov 29, 102 07:00:21 pm" To: mikelin@MIT.EDU (Mike Lin) Date: Sat, 30 Nov 2002 22:47:11 +0100 (MET) Cc: warplayer@free.fr, caml-list@inria.fr, malekith@pld-linux.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > The problem is what *assembly code* should be generated for function f? > > Code to add 2 integers or code to add 2 floats? Hmm.. we'll have a > > problem then. Or maybe both? And choose versions of f based on type it > > is applied to? But then consider: > > > > let f x1 x2 ... xn = ((x1 + x1), (x2 + x2), ..., (xn + xn)) > > > > you need to generate 2^n versions of f. We're getting to ugly things > > like C++ templates here. > > If this is really a problem then what gets generated when you write any > polymorphic function at all? The proposal is to allow constrained > polymorphism; the polymorphism that is already in OCaml seems to > supersede this with regard to the above objection. > > I wonder if the unification algorithm can be generalized to intersect > sets of allowable types instead of unifying "for all" type variables. > It doesn't seem too ludicrous in principle but I could easily have > missed some nasty corner case. > > -Mike Yes: I suspect a really nasty corner in this area. As far as I remember, the kind of types you suggest is known as ``intersection types'', and the type reconstruction problem for languages featuring those types is just undecidable. The big problem with this kind of stuff is to restrict the type schemes allowed in your type system such that you do not fall into the undecidable general case, while still maintaining a powerful enough type system to properly typecheck the function double (fun x -> x + x). Unfortunately, this far from trivial... Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/ ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners