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 LAA32488; Mon, 19 Nov 2001 11:39:13 +0100 (MET) 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 LAA00007 for ; Mon, 19 Nov 2001 11:39:12 +0100 (MET) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAJAdBb13903 for ; Mon, 19 Nov 2001 11:39:11 +0100 (MET) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.11.6/2001082200) with ESMTP id fAJAdBP12309 for ; Mon, 19 Nov 2001 11:39:11 +0100 (CET) Received: from mail.cs.uni-sb.de (IDENT:EamWyboJ2QMav7kcbkbfstLCdftwQNDg@mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.12.1/2001100800) with ESMTP id fAJAdAN09142 for ; Mon, 19 Nov 2001 11:39:10 +0100 (CET) Received: from ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.12.1/2001110800) with ESMTP id fAJAd8D06745 for ; Mon, 19 Nov 2001 11:39:08 +0100 (CET) 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.2/8.11.0) with ESMTP id fAJAd8b05194; Mon, 19 Nov 2001 11:39:08 +0100 Message-ID: <3BF8E14C.BE31359E@ps.uni-sb.de> Date: Mon, 19 Nov 2001 11:39:08 +0100 From: Andreas Rossberg Organization: =?iso-8859-1?Q?Universit=E4t?= des Saarlandes X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Re: variance, subtyping and monads... oh, my! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk james woodyatt wrote: > > 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 *) Almost, except for the inverted variance annotation. It should be: type (-'domain,+'range) (->) > 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? By programming in Java, for example? ;-) Seriously, when speaking about type systems the term "polymorphism" usually refers to parametric polymorphism, witnessed by type constructors like "list" or polymorphic functions like List.map, where type variables pop up. Some OO languages have this kind of polymorphism, e.g. Eiffel, or C++ with its templates (although the latter is rather a macro language than a typeful concept). Many do not. The OO world tends to use the same term to describe subtyping polymorphism, but that arguably is a slight abuse of terminology, at least IMHO. There are even more forms of polymorphism, but I stop here. > 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?) No, as Francois suggested here I just meant functional programming without mixing in OO. > 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? Mh, I don't see what monads have to do with object-oriented concepts. Monads are (besides other things) useful to integrate imperative stuff into a language without giving up referential transparency, or to sequentialise actions in a non-strict language. But this is only related to OO in the sense that OO usually builds upon imperative programming (so that stateful objects have to live inside a monad in pure functional languages). Also, I am not sure what particular concept of encapsulation you are referring to. Monads are a tool to build abstractions and as such they of course encapsulate stuff. But I would argue that the sort of encapsulation usually performed with classes and objects is more related to modules and plain closures (1st-class functions). > Here's my question: Am I missing some important clue about what monads > will get me? Maybe. I don't often use monads myself, so I am by no means an expert, but there are quite some useful applications, even outside the realm of lazy evaluation and purely functional languages. Examples are encapsulating state, failure, non-determinism, etc. I think Markus Mottl posted an OCaml example of a simple monadic evaluator some time ago. And here is one of the more readable, not too Haskell-centric papers: http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html#marktoberdorf -- 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. ------------------- 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