On Thursday 09 August 2007 04:02, Seth Gordon wrote:
> I feel like I still don't understand comonads.
If you haven't done so already, you might like to check out:
"(Co)Monads for Grad Students"
http://www.cas.mcmaster.ca/~carette/CAS706/F2006/presentations/comonads.pdf
"Codata and Comonads in
Kim-Ee Yeoh wrote:
Seth Gordon wrote:
Functors are a generalization from lists to "things that can be mapped
over" in general, and then monads are a generalization of functors.
Way to go! That way lies true co/monadic enlightenment.
I feel like I still don't understand comonads. Maybe I j
Seth Gordon wrote:
>
> Functors are a generalization from lists to "things that can be mapped
> over" in general, and then monads are a generalization of functors.
>
Way to go! That way lies true co/monadic enlightenment. Put another way,
monads are no more about (only) IO/sequencing than fmap
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 val
Ok,
I am guessing that if you were Neo in The Matrix, you would have taken
the Blue Pill. Blue Pill people ask How.
I suspect most people attracted to Haskell have already taken the Red
Pill. Red Pill people ask Why.
It is compulsion, not self-interest, that drives Red Pill people to look
On 8/2/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
> I feel that talking about Monads without Kleisli arrows is like
> talking about category theory without arrows, or at least sets without
> functions. In each case, without the latter, the former is more or
> less useless.
The chapter on monads in
On 8/2/07, Seth Gordon <[EMAIL PROTECTED]> wrote:
> Haskell solves the "how can I do I/O in a pure functional language"
> problem by *turning the world inside-out*. Instead of taking data from
> the mutable outside world, using functions to manipulate it, and
> depositing results back into that wo
On 8/2/07, Dougal Stanton <[EMAIL PROTECTED]> wrote:
> Do I have an suggestions? Well, maybe the right way would be to do as
> we do with map and fold, etc: show the explicitly recursive example,
> then generalise. So, show how we could we would thread state in
> Haskell, or how we would do optiona
> 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'
e-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Reinke
Sent: Thursday, August 02, 2007 12:18 AM
To: haskell-cafe@haskell.org
Subject: Re: FW: RE [Haskell-cafe] Monad Description For Imperative Programmer
a Monad is a type constructor with two operations, implementing
a
On 02/08/07, Alexis Hazell <[EMAIL PROTECTED]> wrote:
> It's at this point that i feel there's an issue. Haskell Monads are used FOR
> many many things. And rather than get to the core of what a Monad is, many
> people provide two or three motivating examples - examples which merely serve
> to sh
On Thursday 02 August 2007 15:57, ok wrote:
> It all depends on what you mean "make sense to".
> I can tell my student that (an instance of Monad) is a type constructor
> applications of which support certain operations that must satisfy
> certain operations. They can memorise that. But it remai
On 2 Aug 2007, at 1:20 pm, Alexis Hazell wrote:
Category theorists can define monads concisely using the language
of their
discipline - surely we can settle on a definition of Haskell Monads
that
would make sense to any programmer who has mastered basic programming
concepts?
It all depends
On 2 Aug 2007, at 5:13 am, alpheccar wrote:
I think the problem is due to a few bad tutorial still available on
the web and which are making two mistakes:
1 - Focusing on the IO monad which is very special ;
2 - Detailing the implementation. As a newie we don't care and we
would prefer to se
Someone asked about comparing monads to loops.
If you are chiefly familiar with the i/o and state monads, that doesn't
really make a lot of sense, but there IS a use of monads which IS a kind
of loop.
Only yesterday I was trying to read someone else's Haskell code where
they had imported Control
On Thursday 02 August 2007 08:17, Claus Reinke wrote:
> a Monad is a type constructor with two operations, implementing
> a standard interface and following a few simple rules.
. . . . and this is one of the best definitions i've seen yet. Thanks Claus!
i think we need to be looking at "What is a
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
> abou
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 comm
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 usu
On 8/1/07, Dan Weston <[EMAIL PROTECTED]> wrote:
> The moral of the story is that monads are less than meets the eye. You
> can create them and concatenate them
I mostly sympathise with your rant, but I think you need to be clearer
about what exactly is concatenated. In general you can't concatena
> The outermost monad (rightmost bound function) is in the driver seat,
and is absolutely free to ignore the monad to its
> left (which in turn encloses monads to its left)! This includes of
> course the main input IO () monad. Don't believe me?
>
> Prelude> const 3 (return "Nuclear waste leakin
> How does all this map to C++? A monad is a a class, with no useful
> interface for the end user, that looks roughly (i.e. I haven't tested
> it) like:
trying to implement it in other languages is a good idea for understanding
monads. I've tried this with the Maybe monad in Lisp:
http://group
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
Kaveh> "A monad is like a loop that can run a new function against
its variable in each iteration."
I’m an imperative programmer learning Haskell, so I’m a newbie,
but I’ll give it a try ☺ Making mistakes is the best way to
learn it ;)
I was a newbie not so long ago so I can understan
My own perspective on monads is this:
In procedural and OO languages, when dealing with compound data
structures, we think in terms of getters (*taking data out* of the
structure) and setters (*putting data in* to the structure).
Languages with some impure functional features (Lisp, Scheme, Perl,
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
> seque
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,
>
> "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. R
Kaveh> "A monad is like a loop that can run a new function against its variable
in each iteration."
I’m an imperative programmer learning Haskell, so I’m a newbie, but I’ll give
it a try ☺ Making mistakes is the best way to learn it ;)
There are lots of different kinds of monads, but let’s sti
On 8/1/07, Andrew Wagner <[EMAIL PROTECTED]> wrote:
> > you can imagine each of the calls to putStrLn gets implicitly passed a
> > variable (here, the world ) and they happen in succession so it's
> > "like a loop".
> It breaks down further as soon as you add any amount of complexity to
> the cod
> say you have this code :
>
>putStrLn "1" >> putStrLn "2" >> putStrLn "3"
>
> you can imagine each of the calls to putStrLn gets implicitly passed a
> variable (here, the world ) and they happen in succession so it's
> "like a loop".
It breaks down further as soon as you add any amount of com
On 8/1/07, david48 <[EMAIL PROTECTED]> wrote:
> As a beginner haskeller coming from an imperative experience, I think
> I understood what he meant.
>
> say you have this code :
>
>putStrLn "1" >> putStrLn "2" >> putStrLn "3"
>
> you can imagine each of the calls to putStrLn gets implicitly pass
On 8/1/07, Andrew Wagner <[EMAIL PROTECTED]> wrote:
> This seems wrong to me. A monad is, first and foremost, a type
> constructor class. I'm not sure how you can really compare that to a
> loop. But perhaps the easiest way to test your definition would be to
> ask this: How is, for example, the Ma
On 01/08/07, Andrew Wagner <[EMAIL PROTECTED]> wrote:
> This seems wrong to me. A monad is, first and foremost, a type
> constructor class. I'm not sure how you can really compare that to a
> loop. But perhaps the easiest way to test your definition would be to
> ask this: How is, for example, the
This seems wrong to me. A monad is, first and foremost, a type
constructor class. I'm not sure how you can really compare that to a
loop. But perhaps the easiest way to test your definition would be to
ask this: How is, for example, the Maybe monad like a loop, in your
definition?
On 8/1/07, Kaveh
On Wednesday 01 August 2007 17:02, Kaveh Shahbazian wrote:
> This is about to put a definition/description to test. So please cooperate!
> ;)
> Is this a useful – sufficient, not complete – definition/description for a
> monad; for an imperative mind: (?)
>
> "A monad is like a loop that can run a
36 matches
Mail list logo
