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 XAA25693; Sun, 18 Nov 2001 23:30:29 +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 XAA25476 for ; Sun, 18 Nov 2001 23:30:28 +0100 (MET) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAIMUQv26541 for ; Sun, 18 Nov 2001 23:30:27 +0100 (MET) Received: from localhost([208.177.152.18]) (3588 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 18 Nov 2001 14:30:25 -0800 (PST) (Smail-3.2.0.111 2000-Feb-17 #5 built 2000-Dec-22) Date: Sun, 18 Nov 2001 14:30:25 -0800 Subject: [Caml-list] Re: variance, subtyping and monads... oh, my! Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) From: james woodyatt To: The Trade Content-Transfer-Encoding: 7bit In-Reply-To: <002001c17035$c722aa80$3363e195@pazo> Message-Id: X-Mailer: Apple Mail (2.472) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk everyone-- I would like to thank all of the OCaml experts who contributed responses to the thread about co-variance, contra-variance and subtyping issues. It helped me confirm for myself that I have a good intuitive grasp of the subject. The next step is learning how to teach it. I'm grateful for the bit about the binomial function type constructor that I can conceptually think about like this: type (+'domain,-'range) (->) = (* yeah, this is pseudo-syntax *) That helped a great deal. Gives me a way to describe something I've never liked about C++ and Java. Oh, and I have a quip to add to the mix, and a question of my own: On Sunday, November 18, 2001, at 05:34 , Andreas Rossberg wrote: > > I hope my explanations clarified that these terms are mainly important > if > you do OO in the presence of polymorphic types. Functional programming > in > its purer forms usually does not use nor require subtyping, so need not > bother with them ;-) How do you do OOP in the *absence* of polymorphic types? Now for the question. First the background: I'm guessing that these "purer forms" of functional programming involve convoluted gyrations with monads and the higher order "things" that you can construct with them by layering them one on top of the other. (What would you call those things? Molecules?) Now, is it my imagination, or is all that research into what you can build out of monads primarily a way for Haskell people to rediscover everything we already know about polymorphism, inheritance and encapsulation? My approach for abstracting DNS resource record types so that my client and server implementations have a modular interface for section processing uses polymorphic variant types and module signatures. It seems pretty lightweight and does what I want. For a brief moment there, I had this nagging concern that maybe I should learn more about these "monad" things before I move on to implementing the DNS client and server modules. I looked into it a little bit, and I decided to stick with the interface I have. As near as I can tell, OCaml doesn't keep me from building monads if I really feel a deep and burning need to do so, but for the life of me I can't figure out what I might get out of it that would be useful and new. The covariant polymorphic type parameter trick that I saw posted to this list a month or so ago seems to produce the same degree of encapsulation and polymorphism I can get with a monad, and I don't *seem* to have all the overhead associated with lazy evaluation and building mad closure chains all over the place. Here's my question: Am I missing some important clue about what monads will get me? Other than further advancement in the Order of the Mystic Knights of the Lambda Calculus, of course. -- j h woodyatt "...the antidote to misinformation is more information, not less." --vinton cerf ------------------- 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