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 XAA04670; Wed, 20 Aug 2003 23:08:08 +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 XAA12669 for ; Wed, 20 Aug 2003 23:08:06 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h7KL85T08801 for ; Wed, 20 Aug 2003 23:08:05 +0200 (MET DST) Received: by rabelais.socialtools.net (Postfix, from userid 108) id E267723311; Wed, 20 Aug 2003 22:08:04 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id CB6C32330E; Wed, 20 Aug 2003 22:08:03 +0100 (BST) Message-ID: <3F43E250.1040903@socialtools.net> Date: Wed, 20 Aug 2003 22:04:16 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: brogoff@speakeasy.net Cc: "caml-list@inria.fr" Subject: Re: [Caml-list] does class polymorphism need to be so complicated? References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG autolearn=ham version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 brogoff:01 caml:01 coerce:01 speakeasy:01 polymorphic:01 compile:02 unit:03 wrote:03 obj:03 inheritance:03 explanation:04 complicated:04 functions:05 polymorphism:06 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk brogoff@speakeasy.net wrote: > If you want to solve your problem, you'll need to coerce, > [...] > A solution using polymorphic methods is sketched next, These are the two options I described in my original post. Both are inconvenient. My original questions remain: Why is upcasting necessary, given that inheritance relationships are known at compile time? Could Caml be modified to correct this problem? Is any work currently being done on this? Why can't methods be polymorphic in the way that functions can be? At the very least, would it be possible to add some syntactic sugar, so we could write: method process (obj : #thing) -> (* ... *) instead of: method process : 'a . (#thing as 'a ) -> unit = fun obj -> (* ... *) It is puzzling that functions provide much better polymorphism than methods; could the Caml experts provide an explanation? Does any of the current research into Caml extensions offer a possibility of improving polymorphism for methods? Ben ------------------- 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