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 TAA05585; Fri, 19 Jul 2002 19:19:07 +0200 (MET DST) 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 TAA05588 for ; Fri, 19 Jul 2002 19:19:06 +0200 (MET DST) Received: from indyio.rz.uni-sb.de (indyio.rz.uni-sb.de [134.96.7.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6JHJ6v24733 for ; Fri, 19 Jul 2002 19:19:06 +0200 (MET DST) Received: from mars.rz.uni-sb.de (IDENT:QyCQ8dYfAyet7r1MaHmLWDgObuXuryGl@mars.rz.uni-sb.de [134.96.7.4]) by indyio.rz.uni-sb.de (8.9.3/8.9.3) with ESMTP id TAA12051307; Fri, 19 Jul 2002 19:19:05 +0200 (CEST) Received: from uni-sb.de (uni-sb.de [134.96.7.230]) by mars.rz.uni-sb.de (8.8.8/8.8.4/8.8.2) with ESMTP id TAA152834633; Fri, 19 Jul 2002 19:19:05 +0200 (CEST) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.12.4/2002060500) with ESMTP id g6JHJ5l04651; Fri, 19 Jul 2002 19:19:05 +0200 (CEST) Received: from mail.cs.uni-sb.de (IDENT:ug9O2bA8/hKADstlvapAZtf+v8ReRBkb@mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.12.1/2002050600) with ESMTP id g6JHJ4Z07381; Fri, 19 Jul 2002 19:19:04 +0200 (CEST) Received: from ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.12.4/2002060500) with ESMTP id g6JHJ2a18711; Fri, 19 Jul 2002 19:19:02 +0200 (CEST) X-Authentication-Warning: email: Host grizzly.ps.uni-sb.de [134.96.186.68] claimed to be ps.uni-sb.de Received: from ps.uni-sb.de (zoidberg.ps.uni-sb.de [134.96.186.121]) by ps.uni-sb.de (8.11.6/8.11.0) with ESMTP id g6JHJ5e19565; Fri, 19 Jul 2002 19:19:05 +0200 Message-ID: <3D384BA1.A883C845@ps.uni-sb.de> Date: Fri, 19 Jul 2002 19:25:53 +0200 From: Andreas Rossberg Organization: =?iso-8859-1?Q?Universit=E4t?= des Saarlandes X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Oleg CC: caml-list Subject: Re: [Caml-list] productivity improvement References: <20020716172916.4903.qmail@web10702.mail.yahoo.com> <200207190821.EAA09974@hickory.cc.columbia.edu> <3D37D474.2551F19E@ps.uni-sb.de> <200207191033.GAA11831@dewberry.cc.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Oleg wrote: > > > And how would you do more complex case analysis, corresponding to nested > > patterns? > > I think I know what nested patterns are (something like > Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty > will come from while using virtual functions. Could you give specific > examples please? Consider a simple expression language again. This time extended with variables and function expressions: type 'a expr = Const of 'a | Var of string | Unop of 'a -> 'a | Binop of 'a -> 'a -> 'a | Lambda of string * 'a expr | Apply of 'a expr * 'a expr Evaluation has to rely on (one-step) reduction (sketch only): let rec reduce1 env = function | Var x -> List.assoc x env | Apply (Lambda (x, e), v) -> eval ((x,v)::env) e | Apply (Unop f, Const x) -> Const (f x) | Apply (Binop f, Const x) -> Unop (f x) | Apply _ -> raise Error | e -> e Doing this with method dispatch requires serious amounts of object spaghetti. I believe you are imaginative enough to see that this is absolutely hopeless for realistic examples with a large number of more complex cases - the number of additional helper methods polluting all your classes will grow exponentially. (And note that even multiple dispatch isn't expressive enough to avoid that.) > > This is more than cumbersome and error-prone in C++ - with > > RTTI, and even more so with method dispatch, where your single algorithm > > will have to be scattered over tons of distant functions. A maintenance > > nightmare. > > Why would maintaining code organized by data type be harder? Isn't it what > encapsulation is all about? No. That's one of the things OO ideology gets wrong. Making the type the unit of encapsulation is much too inflexible. Often you want to encapsulate several types simultanously, e.g. when you have functions operating on a group of closely related types, which cannot sensibly be implemented knowing only one of the types' internals. Thus orthogonalising types and modules is a definite plus. -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids; I mean if Pac Man affected us as kids, we would all be running around in darkened rooms, munching magic pills, and listening to repetitive electronic music." - Kristian Wilson, Nintendo Inc. ------------------- 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