On 8/1/07, Jeff Polakow [EMAIL PROTECTED] wrote:
But what about an actual object of type 'IO
Int', say?
I usually describe the type resulting from applying a monad a computation.
Same here. If m is a monad, then m a is a computation. (Of course,
computations are first-class values, like
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of peterv
However, one thing which I find annoying is that a classic
pure function cannot evaluate an IO function unless you use
unsafePerformIO; one must promote (?demote) the pure
function into the IO monad.
That's just a
On 8/1/07, Andrew Wagner [EMAIL PROTECTED] wrote:
For me, I think the key to monads is to really
understand 2 things about them:
...
2.) Monads are about sequencing
Now I disagree on 2.
Monads are no more about sequencing than binary operators are about
sequencing. Sure, if you want to, you
an IO monad is a delayed action that will be executed as soon as that action
is needed for further evaluation of the program.
I'm not sure I like this, as it seems to confuse the issue. An expert
should correct me if I'm wrong, but monads in and of themselves don't
depend on laziness.
Hello,
On 8/1/07, Andrew Wagner [EMAIL PROTECTED] wrote:
For me, I think the key to monads is to really
understand 2 things about them:
...
2.) Monads are about sequencing
Now I disagree on 2.
Monads are no more about sequencing than binary operators are about
sequencing. Sure, if
Here's my rant about the way monads are explained in Haskell tutorials
(which are much too polluted with nuclear waste to be safely approached):
It is a big mistake to start with the IO monad. It pollutes and
misdirects the understanding of what a monad is. The dreaded nuclear
waste metaphor
Hello,
'Monad' is a type class.
So what's 'IO'? Is the correct terminology 'instance' as in 'IO is an
instance of Monad'. I consider 'IO' to be 'a monad' as that fits with
mathematical terminology.
I agree with this.
But what about an actual object of type 'IO
Int', say?
I usually
a Monad is a type constructor with two operations, implementing
a standard interface and following a few simple rules.
the Monad type class tells you the interface (what operations
you've got, and their types), the Monad laws tell you what all
types implementing that interface should have in
I knew someone was going to catch me wandering into the deep end of the
pool!
Having read large parts of your blog, I would never presume to tell you
anything about Haskell or category theory, but what the hell...
I mostly sympathise with your rant, but I think you need to be clearer
about
