Paul Hudak wrote:
[I]n the one-of-many ways that I view monads, a monad is just a high-order
function that abstracts away function composition. In particular, if I
have an action f, and an action g, I can think of them as recipes, because
I can combine them via f = g. It's only after I
On Tue, Aug 14, 2007 at 05:53:05PM -0700, Michael Vanier wrote:
For what it's worth, the nature of Haskell is such that you do (at
least currently) have to spend a lot of time reading research papers
to understand what's going on. Maybe that will change sometime, but
probably not soon. This
I've seen the analogy with recipes used before, but I think that you
need to be careful when you try to distinguish the analogy to monads
from the analogy to functions. The reason is that, in the one-of-many
ways that I view monads, a monad is just a high-order /function /that
abstracts away
Ronald Guida wrote:
Here is the brief explanation I came up with:
Arrows and monads are abstract data types used to construct Domain
Specific Embedded Languages (DSELs) within Haskel. A simple arrow
provides a closed DSEL. A monad is a special type of arrow that
creates an open
On 14/08/07, Ronald Guida [EMAIL PROTECTED] wrote:
My present goal is to understand monads well enough to be able to
explain them to others. I wonder if it's possible to create a
tutorial that explains monads well enough so that they just make
sense or click for people.
It seems everyone
Having just gone through all the tutorials and things (again but
this time I think it stuck) the Haskell community is on the wrong
track as far as teaching Monads to new programmers.
If I were teaching addition and multiplication to children I
wouldn't start with, We'll begin by defining an
On 14/08/07, Lanny Ripple [EMAIL PROTECTED] wrote:
Having just gone through all the tutorials and things (again but
this time I think it stuck) the Haskell community is on the wrong
track as far as teaching Monads to new programmers.
If I were teaching addition and multiplication to children
Hello,
There is clearly a problem with the Haskell/monad tutorials out there...
The tutorials seriously need to step back and start with
something like, To enforce order of evaluation we evaluate
closures* returning a defined type. The first closure will feed
its result to the second
Look! You are doing it again! :) Does that paragraph even
contain the word Monad? :)
I'm aware a monad is an abstraction and as such it doesn't *do*
anything. My point was along the lines that you don't need to
know that your working in a field to be able to learn that
3/2 = 1.5
.
Hallo,
On 8/14/07, Jeff Polakow [EMAIL PROTECTED] wrote:
Hello,
There is clearly a problem with the Haskell/monad tutorials out there...
The tutorials seriously need to step back and start with
something like, To enforce order of evaluation we evaluate
closures* returning a defined
On 8/14/07, Jeff Polakow [EMAIL PROTECTED] wrote:
One general intuition about monads is that they represent computations
rather than simple (already computed) values:
x :: Int -- x is an Int
x :: Monad m = m Int -- x is a computation of an Int
What's a computation? It
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I like the very light weight analogy (which works for most practical
uses of monads) that a monadic action is a recipe
Many introductory programming books present the idea of a program as a
recipe. Here's a recipe for computing factorials:
Hello,
Look! You are doing it again! :) Does that paragraph even
contain the word Monad? :)
Sorry. Your first paragraph led me to believe you were writing about
monads.
I'm aware a monad is an abstraction and as such it doesn't *do*
anything. My point was along the lines that you
On Tue, 2007-08-14 at 09:55 -0500, Lanny Ripple wrote:
Having just gone through all the tutorials and things (again but
this time I think it stuck) the Haskell community is on the wrong
track as far as teaching Monads to new programmers.
If I were teaching addition and multiplication to
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I like the very light weight analogy (which works for most practical
uses of monads) that a monadic action is a recipe
Many introductory programming books present the idea of a program as
A very good point. I even knew that implicitly but wasn't
thinking in those terms explicitly when writing up my first post
and it does make a difference in how you view things.
-ljr
Jeff Polakow wrote:
Hello,
Look! You are doing it again! :) Does that paragraph even
contain the
You don't normally call x::Int a computation of an Int because there's
nothing that distinguishes the value of the x from what it was before you
computed it. So I prefer to regard x as a value (in a domain, of course).
But for x :: (Monad m) = m Int there is something else happening, so the
word
Derek Elkins wrote:
What people need to do is stop reading two page blog posts by someone
who's just got monads and read the well-written peer-reviewed papers
I have taught many people to program in group settings and
individually in my career. I have referred them to many
tutorials. I
Hello,
On 8/14/07, Jeff Polakow [EMAIL PROTECTED] wrote:
One general intuition about monads is that they represent computations
rather than simple (already computed) values:
x :: Int -- x is an Int
x :: Monad m = m Int -- x is a computation of an Int
What's a
On 14/08/07, Jeff Polakow [EMAIL PROTECTED] wrote:
Of course, the type [Int] denotes a value which is a list of Ints;
additionally [Int] can be viewed as a value representing the
nondeterministic computation of a single Int. Generally, the type Monad m =
m Int can be viewed as a value
On 8/14/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
You don't normally call x::Int a computation of an Int because there's
nothing that distinguishes the value of the x from what it was before you
computed it.
Can you spell out exactly what you mean by this?
So I prefer to regard x as a
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
Where do monads come in?
Well I would try to distinguish between code that we write to compute
values, and values which represent monadic actions when coming up with
analogies.
How would
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
Where do monads come in?
Well I would try to distinguish between code that we write to compute
values, and values which represent
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Well that's easy, don't use the recipe analogy to explain code, use it
for monadic values exclusively, and you avoid the confusion entirely!
I don't think it's that complicated.
It certainly is complicated. I think I have a good grasp of
Hello,
On 14/08/07, Jeff Polakow [EMAIL PROTECTED] wrote:
Of course, the type [Int] denotes a value which is a list of Ints;
additionally [Int] can be viewed as a value representing the
nondeterministic computation of a single Int. Generally, the type
Monad m = m Int can be viewed as a
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
On 8/14/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Well that's easy, don't use the recipe analogy to explain code, use it
for monadic values exclusively, and you avoid the confusion entirely!
I don't think it's that complicated.
It
Dan Piponi wrote:
| On 8/14/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
| You don't normally call x::Int a computation of an Int because there's
| nothing that distinguishes the value of the x from what it was before
| you computed it.
|
| Can you spell out exactly what you mean by this?
Dan Piponi, Tue, 14 Aug 2007 11:52:16 -0700:
All functions can be viewed as recipes. (+) is a recipe. Give me some
ingredients (two numbers) and I'll use (+) to give you back their sum.
(+) is not a recipe, it is a chef. On the other hand,
(return 5 :: State Integer) is a recipe. You need a
On 14/08/07, Malte Milatz [EMAIL PROTECTED] wrote:
Dan Piponi, Tue, 14 Aug 2007 11:52:16 -0700:
All functions can be viewed as recipes. (+) is a recipe. Give me some
ingredients (two numbers) and I'll use (+) to give you back their sum.
(+) is not a recipe, it is a chef. On the other hand,
Sebastian Sylvan wrote:
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
If I was one of your students and you said that monads are recipes I
would immediately ask you where the monads are in my factorial program
regardless of whether you had introduced one or two different
analogies for
On 14/08/07, Seth Gordon [EMAIL PROTECTED] wrote:
Sebastian Sylvan wrote:
On 14/08/07, Dan Piponi [EMAIL PROTECTED] wrote:
If I was one of your students and you said that monads are recipes I
would immediately ask you where the monads are in my factorial program
regardless of whether you
On Tue, 2007-08-14 at 12:40 -0500, Lanny Ripple wrote:
Derek Elkins wrote:
What people need to do is stop reading two page blog posts by someone
who's just got monads and read the well-written peer-reviewed papers
I have taught many people to program in group settings and
individually in
For what it's worth, the nature of Haskell is such that you do (at least currently) have to spend a
lot of time reading research papers to understand what's going on. Maybe that will change sometime,
but probably not soon. This ties in to the open-endedness of Haskell; I sometimes think that
On Mon, 2007-08-13 at 19:31 +0200, peterv wrote:
When I read side-effects, I understand it as unwanted effects, like
aliasing, and effects depending on the order of execution. I'm not sure
if my understanding here is correct. I hope Haskell does not allow
side-effects but only effects, meaning
explanation of
how a Monad can allow for side effects (at least the IO Monad). - Greg
- Original Message
From: peterv [EMAIL PROTECTED]
To: Kim-Ee Yeoh [EMAIL PROTECTED]; haskell-cafe@haskell.org
Sent: Monday, August 13, 2007 10:31:48 AM
Subject: RE: [Haskell-cafe] Explaining monads
Ronald
Ronald Guida wrote:
Given the question What is a Monad, I would have to say A Monad is
a device for sequencing side-effects.
peterv [EMAIL PROTECTED] wrote:
Side-effects is a piece of linguistic cruft played fast-and-loose
by too many people in this game. Sequencing suffers the same
On 11/08/07, Ronald Guida [EMAIL PROTECTED] wrote:
Here's my interpretation of the table:
--
Structure | Subject | Action| Verb | Result
+--+++--
function
Ronald Guida wrote:
Given the question What is a Monad, I would have to say A Monad is
a device for sequencing side-effects.
There are side-effects and there are side-effects. If the only
monad you use is Maybe, the only side-effect you get is a slight
warming of the CPU.
Dave Menendez
]
[mailto:[EMAIL PROTECTED] On Behalf Of Kim-Ee Yeoh
Sent: Monday, August 13, 2007 15:30
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Explaining monads
Ronald Guida wrote:
Given the question What is a Monad, I would have to say A Monad is
a device for sequencing side-effects
Stefan O'Rear wrote:
On Sat, Aug 11, 2007 at 03:00:04PM -0400, Ronald Guida wrote:
The question remains: What is special about Monad or ArrowApply,
compared to Arrow? or What is more general about Arrow, compared
to Monad or ArrowApply?
If all you have is an Arrow, then you must make up
Ronald Guida wrote:
Here's a toy language, described by a regular expression:
0(10)*110
I want to read characters, one at a time, and eventually decide to
Accept or Reject a string.
Let me try to understand my options.
* With a simple Arrow, I can create a fixed sequence of read
Tillmann Rendel wrote:
Ronald Guida wrote:
Here's a toy language, described by a regular expression:
0(10)*110
I want to read characters, one at a time, and eventually decide to
Accept or Reject a string.
Let me try to understand my options.
* With a simple Arrow, I can create a fixed
David Menendez wrote:
This is probably because no one has found a compelling use case for
comonadic-style programming in Haskell. There have been some
interesting papers, such as Comonadic functional attribute
evaluation by Uustalu and Vene, but nothing as compelling as Wadler's
Monads
On 8/10/07, Ronald Guida [EMAIL PROTECTED] wrote:
Kim-Ee Yeoh wrote:
Monads are undoubtedly more pervasive, and that could be because there
aren't as many arrow and comonad tutorials, atomic ones or otherwise.
Moreover, Comonad isn't even in the standard libraries (Hoogle returns
no
ronguida:
Monads are undoubtedly more pervasive, and that could be because there
aren't as many arrow and comonad tutorials, atomic ones or otherwise.
Moreover, Comonad isn't even in the standard libraries (Hoogle returns
no results for it).
When I searched for tutorials on monads, I
Ronald Guida wrote:
Here's my interpretation of the table:
--
Structure | Subject | Action| Verb | Result
+--+++--
function| a | a-b
David Menendez wrote:
Be sure to read sigpfe's You could have invented monads! and the
Wadler paper.
http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html
http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf
Most tutorials try to explain what a monad
On Sat, Aug 11, 2007 at 03:00:04PM -0400, Ronald Guida wrote:
The question remains: What is special about Monad or ArrowApply,
compared to Arrow? or What is more general about Arrow, compared to
Monad or ArrowApply?
If all you have is an Arrow, then you must make up your mind what you're
going
Brian Brunswick-5 wrote:
g f ??? g ??? f
application a a-b flip ($) b
monad bind m a a-m b= m b
comonad cobind w a w a-b= w b
arrowarr a b arr b c arr
Brian Brunswick wrote:
g f ??? g ??? f
application a a-b flip ($) b
monad bind m a a-m b= m b
comonad cobind w a w a-b= w b
arrowarr a b arr b c arr a c
50 matches
Mail list logo
