caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: james woodyatt <jhw@wetware.com>
To: The Trade <caml-list@inria.fr>
Subject: [Caml-list] Re: variance, subtyping and monads... oh, my!
Date: Sun, 18 Nov 2001 14:30:25 -0800	[thread overview]
Message-ID: <DCC4EB14-DC73-11D5-963F-000502DB38F5@wetware.com> (raw)
In-Reply-To: <002001c17035$c722aa80$3363e195@pazo>

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) (->) = <fun>  (* 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 ;-)

<quip>How do you do OOP in the *absence* of polymorphic types?</quip>

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 <jhw@wetware.com>
"...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


  parent reply	other threads:[~2001-11-18 22:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-16 19:37 [Caml-list] [Q]: Co(ntra)variance and subtyping? Clemens Hintze
2001-11-17 14:18 ` Mark Wotton
2001-11-17 14:55   ` Mark Wotton
2001-11-17 17:50   ` [Caml-list] " Clemens Hintze
2001-11-17 23:17     ` Mark Wotton
2001-11-18  9:16       ` Clemens Hintze
2001-11-18 13:18         ` Alain Frisch
2001-11-19  9:54           ` Remi VANICAT
     [not found]       ` <9t7v4d$gij$1@qrnik.zagroda>
2001-11-18 11:57         ` Marcin 'Qrczak' Kowalczyk
2001-11-18 13:34 ` [Caml-list] " Andreas Rossberg
2001-11-18 21:22   ` Pixel
2001-11-19  0:33     ` Jacques Garrigue
2001-11-18 22:35       ` David Gurr
2001-11-19  7:24         ` [Caml-list] " Clemens Hintze
2001-11-19 12:03           ` Markus Mottl
2001-11-19  8:29         ` [Caml-list] " Xavier Leroy
2001-11-19 11:03       ` Alain Frisch
2001-11-20  9:58         ` Didier Remy
2001-11-19 11:14       ` Pixel
2001-11-18 22:30   ` james woodyatt [this message]
2001-11-19  8:11     ` [Caml-list] Re: variance, subtyping and monads... oh, my! Francois Pottier
2001-11-19  9:02       ` james woodyatt
2001-11-19  9:58         ` Markus Mottl
2001-11-19 20:47           ` james woodyatt
2001-11-19 12:56       ` Frank Atanassow
2001-11-19 10:39     ` Andreas Rossberg
2001-11-19 12:21       ` Markus Mottl
2001-11-19 13:43         ` [Caml-list] Kylix and OCaml Christophe Raffalli
2001-11-20  2:05           ` Vitaly Lugovsky
2001-11-20  8:51             ` Christophe Raffalli
2001-11-22  1:42               ` Vitaly Lugovsky
2001-11-20 10:00             ` Benjamin Monate
2001-11-20 10:24               ` [Caml-list] [Bug in an interface between C++ and OCAML due to some pointer encapsulation] Sylvain Kerjean
2001-11-20 12:14             ` [Caml-list] Kylix and OCaml Maxence Guesdon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DCC4EB14-DC73-11D5-963F-000502DB38F5@wetware.com \
    --to=jhw@wetware.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).