Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: computation vs function (Daniel Carrera)
2. Re: computation vs function (Andrew Wagner)
3. Re: computation vs function (Daniel Fischer)
4. Re: computation vs function (Philippa Cowderoy)
5. Re: computation vs function (Philippa Cowderoy)
6. Re: computation vs function (Philippa Cowderoy)
7. Re: computation vs function (Ertugrul Soeylemez)
8. doing state right (Floptical Logic)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Apr 2009 23:06:02 +0200
From: Daniel Carrera <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Brent Yorgey wrote:
> "Computation" does not really have any technical meaning, it's just
> supposed to be an intuition. But the term "computation" is often used
> to refer to things of type (m a) where m is a Monad. You can clearly
> see from the types that something of type (m a) is different than
> something of type (a -> b). The former takes no inputs and somehow
> produces value(s) of type a; the latter takes something of type a as
> input and produces something of type b as output.
>
> However, you could also legitimately thing of things of type (a -> b)
> as "computations"; more interestingly, you can think of things of type
> (a -> m b) as "parameterized computations" which can be composed in
> nice ways.
>
> Don't rely too heavily on the "computation" idea; monads certainly
> don't "revolve around computations", it's only one particular way of
> giving intuition for monads which does.
Thanks. That helps a lot.
It looks to me that one could replace the word "computation" everywhere
in the article with "monadic type" (where again, "monadic type" is just
an intuition for "m a" where m is a Monad) and the article would be
equally correct. Am I right?
The Wikipedia article seems to use "monadic type" for the same things
that ertes calls "computation".
I can't decide which term gives better intuition. The term "computation"
makes binding more intuitive: The computation (m a) returns a value of
type "a" can then be fed into a function of type (a -> m b). On the
other hand, "monadic type" is more intuitive when you write "Maybe Int"
or "IO String".
Anyways, thanks for the help. I'm (slowly) making progress.
Cheers,
Daniel.
------------------------------
Message: 2
Date: Wed, 22 Apr 2009 17:13:42 -0400
From: Andrew Wagner <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: Daniel Carrera <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I kind of like the term "monadic action" myself. Here's another perspective
that may help you out:
I really like the idea of the "programmable semicolon". That is, in your
typical programming languages, you're really working in an implicit State
monad. All the in-scope state is carried over from line to line, and each
line is separated by a semicolon.
In Haskell, we first get rid of this. We don't like the idea of being able
to modify state without being explicit about the types. But of course we
still allow you to carry state around. You use >>= to bind "lines" together
to use the same state. That's when you get to really take things a step
further, though: because state isn't the only "side effect" which you can
capture and hide away in a >>=. You can do it with IO, non-determinism,
potential failure, etc., etc. And that's where monads come in. It's an
interface for gluing together actions with "side effects" in a way in which
the actual effects are explicit, but hidden away in the class instance.
Hope this helps!
On Wed, Apr 22, 2009 at 5:06 PM, Daniel Carrera <
[email protected]> wrote:
> Brent Yorgey wrote:
>
>> "Computation" does not really have any technical meaning, it's just
>> supposed to be an intuition. But the term "computation" is often used
>> to refer to things of type (m a) where m is a Monad. You can clearly
>> see from the types that something of type (m a) is different than
>> something of type (a -> b). The former takes no inputs and somehow
>> produces value(s) of type a; the latter takes something of type a as
>> input and produces something of type b as output.
>>
>> However, you could also legitimately thing of things of type (a -> b)
>> as "computations"; more interestingly, you can think of things of type
>> (a -> m b) as "parameterized computations" which can be composed in
>> nice ways.
>>
>> Don't rely too heavily on the "computation" idea; monads certainly
>> don't "revolve around computations", it's only one particular way of
>> giving intuition for monads which does.
>>
>
> Thanks. That helps a lot.
>
> It looks to me that one could replace the word "computation" everywhere in
> the article with "monadic type" (where again, "monadic type" is just an
> intuition for "m a" where m is a Monad) and the article would be equally
> correct. Am I right?
>
> The Wikipedia article seems to use "monadic type" for the same things that
> ertes calls "computation".
>
> I can't decide which term gives better intuition. The term "computation"
> makes binding more intuitive: The computation (m a) returns a value of type
> "a" can then be fed into a function of type (a -> m b). On the other hand,
> "monadic type" is more intuitive when you write "Maybe Int" or "IO String".
>
> Anyways, thanks for the help. I'm (slowly) making progress.
>
> Cheers,
> Daniel.
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090422/da872308/attachment-0001.htm
------------------------------
Message: 3
Date: Wed, 22 Apr 2009 23:54:44 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Am Mittwoch 22 April 2009 23:06:02 schrieb Daniel Carrera:
> The Wikipedia article seems to use "monadic type" for the same things
> that ertes calls "computation".
>
> I can't decide which term gives better intuition. The term "computation"
> makes binding more intuitive: The computation (m a) returns a value of
> type "a" can then be fed into a function of type (a -> m b). On the
> other hand, "monadic type" is more intuitive when you write "Maybe Int"
> or "IO String".
Yes, different expressions give better pictures for different aspects.
I think the term computation is meant to hint that the computations in one
monad share a
common structure, much more so than general functions, so a different term was
chosen.
Of course computations in different monads have different structures, but even
these have
common aspects (which are then captured in the Monad type class).
>
> Anyways, thanks for the help. I'm (slowly) making progress.
>
> Cheers,
> Daniel.
Cheers,
Daniel
------------------------------
Message: 4
Date: Wed, 22 Apr 2009 22:59:07 +0100
From: Philippa Cowderoy <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: Andrew Wagner <[email protected]>
Cc: [email protected]
Message-ID: <1240437547.16004.5.ca...@flippa-eee>
Content-Type: text/plain
On Wed, 2009-04-22 at 17:13 -0400, Andrew Wagner wrote:
> I kind of like the term "monadic action" myself.
Action's great for IO, but it's less so for monads like lists that
aren't particularly about imperative ideas of computation. I still talk
about IO actions though.
--
Philippa Cowderoy <[email protected]>
------------------------------
Message: 5
Date: Wed, 22 Apr 2009 23:00:05 +0100
From: Philippa Cowderoy <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: Daniel Carrera <[email protected]>
Cc: [email protected]
Message-ID: <1240437605.16004.6.ca...@flippa-eee>
Content-Type: text/plain
On Wed, 2009-04-22 at 23:06 +0200, Daniel Carrera wrote:
> It looks to me that one could replace the word "computation" everywhere
> in the article with "monadic type" (where again, "monadic type" is just
> an intuition for "m a" where m is a Monad) and the article would be
> equally correct. Am I right?
>
Maybe for that article, but generally it's the values that are
computations, not the types.
--
Philippa Cowderoy <[email protected]>
------------------------------
Message: 6
Date: Wed, 22 Apr 2009 23:01:50 +0100
From: Philippa Cowderoy <[email protected]>
Subject: Re: [Haskell-beginners] computation vs function
To: [email protected]
Message-ID: <1240437710.16004.8.ca...@flippa-eee>
Content-Type: text/plain
On Wed, 2009-04-22 at 22:38 +0200, Daniel Carrera wrote:
> Hello,
>
> I have finished the tutorial at http://ertes.de/articles/monads.html and
> my understanding of monads has increased greatly. I still need to cement
> some concepts in my mind. What exactly is the difference between a
> computation and a function? Monads revolve around computations, so I'd
> like to understand computations better.
>
Computations are like "procedures" in other languages - you run them[1],
they yield a value. Conceptually, functions are (potentially infinite)
maps from their input to their output. We sometimes call functions with
types like "Int -> IO ()" monadic functions as well, which may also mean
the combination of the function and then the computation that results -
by analogy to functions in languages like C.
[1] Sometimes the runtime system runs them for you, like main. Sometimes
the computation is already its (lazily evaluated) output, like with
lists or Maybe.
--
Philippa Cowderoy <[email protected]>
------------------------------
Message: 7
Date: Thu, 23 Apr 2009 01:10:28 +0200
From: Ertugrul Soeylemez <[email protected]>
Subject: [Haskell-beginners] Re: computation vs function
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Daniel Carrera <[email protected]> wrote:
> I have finished the tutorial at http://ertes.de/articles/monads.html
> and my understanding of monads has increased greatly. I still need to
> cement some concepts in my mind. What exactly is the difference
> between a computation and a function? Monads revolve around
> computations, so I'd like to understand computations better.
What I refer to as a 'computation' in the article is actually just a
value of type 'Monad m => m a'. I have chosen that term, because you
can apply it to any monad I've seen. As mentioned in section 5, you can
think of 'Just 3' as being a computation, which results in 3. But it's
important that this is not a function, but just an independent value.
You can think of a function of type 'a -> b' as a parametric value -- a
value of type 'b' depending on some value of type 'a'. That makes a
function of type 'Monad m => a -> m b' a parametric computation. A
computation, where something is missing, like with an open slot, where
you need to plug a cable in first.
By the way, this is where (>>=) comes into play. If you have a
computation, which needs a value, but that value comes as the result of
another computation, you can use the binding operator.
f :: Monad m => a -> m b
The 'f' function is a parametric computation of type 'm b', which
depends on a value of type 'a'. Now if
c :: Monad m => m a
and 'm' and 'a' in 'f' are the same as 'm' and 'a' in 'c', then
c >>= f
takes 'c', puts its result (of type 'a') into 'f', resulting in a
computation of type 'm b'.
Example: You have a computation 'myComp', which outputs a string to
stdout prefixed with "+++ ":
myComp :: String -> IO ()
myComp str = putStrLn ("+++ " ++ str)
If that string is available directly, just pass it to 'myComp', which
results in a computation. If that string is not available directly, but
comes as the result of another computation 'getLine', you use (>>=):
getLine >>= myComp
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
------------------------------
Message: 8
Date: Thu, 23 Apr 2009 00:59:37 -0500
From: Floptical Logic <[email protected]>
Subject: [Haskell-beginners] doing state right
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
I am using a PPM library to generate a square image where each white
pixel represents a prime number. The PPM library takes a function
(Int -> Int -> Colour) to create the image. This interface isn't
ideal but it is what I have to work with. I am convinced that using a
sieve is faster than testing every pixel in the image for primality,
but the (Int -> Int -> Colour) interface makes this awkward. The code
below attempts to treat the list of prime numbers as a stack via
global mutable state, popping the head whenever the pixel is prime.
Obviously this is not idiomatic Haskell. What is the correct approach
of dealing with state here? Thanks for reading.
import ONeillPrimes
import PPM6
import Colour
import Data.IORef
import System.IO.Unsafe
limit = 2000
slimit = limit*limit
primeList = takeWhile (<=slimit) primes
p :: IORef [Int]
p = unsafePerformIO (newIORef primeList)
pcol n = unsafePerformIO $ do
xs <- readIORef p
if null xs then return black else
if n == head xs
then do
writeIORef p (tail xs)
return white
else
return black
main = quick_ppm "foo.ppm" (\i j -> pcol ((i-1)*limit+j)) limit limit
-- quick_ppm :: FilePath -> (Int -> Int -> Colour.Colour) -> Int -> Int -> IO ()
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 10, Issue 22
*****************************************
