Re: [Caml-list] Re: variance, subtyping and monads... oh, my!

[Andreas Rossberg <rossberg@ps.uni-sb.de>]

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) (->) = <fun>  (* 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 ;-)
> 
> <quip>How do you do OOP in the *absence* of polymorphic types?</quip>

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