Send Beginners mailing list submissions to
beginners@haskell.org
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
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Spacewars! clone needs code review (Aur Saraf)
2. Re: = vs <- (Ertugrul Soeylemez)
3. monad nomad gonad gomad (prad)
4. Re: Re: = vs <- (Kyle Murphy)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 Aug 2010 23:29:44 +0300
From: Aur Saraf <sonofli...@gmail.com>
Subject: [Haskell-beginners] Spacewars! clone needs code review
To: beginners@haskell.org
Message-ID:
<aanlktinykkcxhhzrwdyxhkm702x6z37wuc2nhsa9y...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello All,
I've been spending all my nights lately on my final self-given Haskell
"learning exercise" - a Spacewar! [http://en.wikipedia.org/wiki/Spacewar!]
clone.
It is playable but lacks the features that perfect a game - score system,
menu etc' - and there's some hacks in areas where I didn't feel that
implementing it prettily would teach me anything.
The game is available under the BSD license in my github [
http://github.com/SonOfLilit/purewars].
I would be very happy if anyone would bother to review my code and suggest
ways that I could improve it, since this is a learning exercise.
Thanks,
-- Aur
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100813/3558af7d/attachment-0001.html
------------------------------
Message: 2
Date: Sat, 14 Aug 2010 02:06:23 +0200
From: Ertugrul Soeylemez <e...@ertes.de>
Subject: [Haskell-beginners] Re: = vs <-
To: beginners@haskell.org
Message-ID: <20100814020623.4fc9a...@tritium.streitmacht.eu>
Content-Type: text/plain; charset=US-ASCII
Kyle Murphy <orc...@gmail.com> wrote:
> Remember that in most cases, once something is "inside" of a monad (IO
> in this case), it's very difficult, impossible, to get it out again.
I think, this is very misleading. You never get "out of a monad", you
get "into" it, and you can do that whenever you want. Remember that the
monadic world is inside of the pure world, not the pure world inside of
the monadic world. In fact, the monadic world is part of it.
The name bound by '<-' is something you can refer to in the pure world.
There is nothing difficult about using the result of a monadic
computation in the pure world. Just give it a name and refer to it, and
that's it.
> The do syntax just adds a convenient abstraction so that you don't
> have to construct complex chains of >>= and >> operations by hand. In
> our limited example this is fairly trivial, but consider something
> like:
>
> main = do
> something <- foo
> blah <- bar something
> moreblah <- baz something blah
> putStrLn moreblah
> putStrLn "really long chain now"
Pretty straightforward:
main =
foo >>= \something ->
bar something >>= \blah ->
baz something blah >>= \moreblah ->
putStrLn moreblah >>
putStrLn "really long chain now"
> which would be translated to:
>
> main = foo >>= (\something -> bar something >>= (\blah -> baz
> something blah >>= (\moreblah -> putStrLn moreblah >> (putStrLn
> "really long chain now"))))
You could just as well write:
main = do { something <- foo; blah <- bar something;
moreblah <- baz something blah; putStrLn moreblah; putStrLn
"really long chain now" }
You are complicating things artifically. For example there is no reason
to have all those parentheses, because (>>=) is associative by
definition.
The do-notation doesn't make nasty things nice. It makes nice things
nicer. Don't be afraid to use raw monadic combinators, because
sometimes they are much better:
main = getArgs >>= mapM_ (readFile >=> putStr)
Much more concise than:
main = do
files <- getArgs
forM_ files $ \file -> do
content <- readFile file
putStr content
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
------------------------------
Message: 3
Date: Fri, 13 Aug 2010 21:39:33 -0700
From: prad <p...@towardsfreedom.com>
Subject: [Haskell-beginners] monad nomad gonad gomad
To: haskellbeginners <beginners@haskell.org>
Message-ID: <20100813213933.7da59...@gom>
Content-Type: text/plain; charset=US-ASCII
ok so taking MAN's suggestion:
"I think It's time for you to get serious with the monads"
that's just what i'm going to do!
i found the following references:
You Could Have Invented Monads!
http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html
an interesting way to become familiar with the idea
Monads for the Working Haskell Programmer
http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm
seems to have several practical ideas there (though i don't understand
them yet)
A tour of the Haskell Monad functions
http://members.chello.nl/hjgtuyl/tourdemonad.html
a nice reference with brief explanations
Explaining Haskell IO without Monads
http://neilmitchell.blogspot.com/2010/01/haskell-io-without-monads.html
possibly a good conceptual aid for background
All About Monads
http://www.haskell.org/all_about_monads/html/index.html
this seems to have everything though it'll take some work to dig in
in any case, monads seem to be a rather important concept to getting
anything done in haskell. for instance, i have a program which is
generating the output it is supposed to (i can print it), but i
can't seem to get it into another function and keep getting the error
i've seen so many times:
Couldn't match expected type `[String]'
against inferred type `IO [String]'
so it's time to understand them.
besides, the stuff looks rather intriguing and certainly appears to
take one into computer language design theory.
any sources others have found useful would be appreciated as well as
suggestions on how to proceed through the above.
in friendship,
prad
--
In friendship,
prad
... with you on your journey
Towards Freedom
http://www.towardsfreedom.com (website)
Information, Inspiration, Imagination - truly a site for soaring I's
------------------------------
Message: 4
Date: Sat, 14 Aug 2010 01:53:48 -0400
From: Kyle Murphy <orc...@gmail.com>
Subject: Re: [Haskell-beginners] Re: = vs <-
To: Ertugrul Soeylemez <e...@ertes.de>
Cc: beginners@haskell.org
Message-ID:
<aanlkti=asmh0hvzdhxoevtbxtpce4e+vayqgm_oia...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Ertugrul Soeylemez <e...@ertes.de> wrote:
> I think, this is very misleading. Â You never get "out of a monad", you
> get "into" it, and you can do that whenever you want. Â Remember that the
> monadic world is inside of the pure world, not the pure world inside of
> the monadic world. Â In fact, the monadic world is part of it.
Not really, it depends on how you look at things. If you want to use
the result of something that returns an IO Monad inside of a pure
function, you really can't do that without in turn making that
function impure (that is, putting it inside of the IO Monad as well),
so to one way of looking at it, values (and functions) exist inside
Monads and with few exceptions are impossible to remove from those
Monads. You can always embed your pure function inside a non-pure
function, but the opposite is not true. Most of the monads do provide
functions like fromJust, and unsafePerformIO (never use this,
seriously) that can allow you to escape from the monad, but doing so
is often risky. The monadic world as you put it, really isn't inside
of the pure world except in theory. From a practical standpoint
everything exists inside the IO monad at some level, it's just lower
level functions that are pure (that is, functions can be pure, but at
some point they MUST be called from the IO monad). I know
theoretically monads are built on top of pure math, but to me the
difference between monads as a concept and monads as implemented in
Haskell, is similar to the difference between proving a program to be
correct, and actually running it.
> You are complicating things artifically. Â For example there is no reason
> to have all those parentheses, because (>>=) is associative by
> definition.
>
> The do-notation doesn't make nasty things nice. Â It makes nice things
> nicer. Â Don't be afraid to use raw monadic combinators, because
> sometimes they are much better:
The example I provided was still relatively simple, and apparently
didn't need all the parentheses, but I wasn't going to bet on it, and
had I used other operators, say some provided by a module, who knows
what kinds of associativity would be involved. I generally always use
parentheses around lambdas if for no other reason than to make it
easier to see what their scope is.
I never said the monad operators were nasty, or that the do notation
was nicer, just that often it is more convenient. There are instances
where I find it simpler and easier to read an expression using the
monad operators rather than do notation, and vice versa, so it really
depends on the particular instance. Sometimes I even find it most
readable to combine the two into something like:
foobar = do
baz <- foo 42
bar baz >>= putStrLn . show . xyzzy baz
Once again, this is not supposed to be a specific example, just a
conceptual one vaguely representative of the form of actual ones I've
run across before.
-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.
On Fri, Aug 13, 2010 at 20:06, Ertugrul Soeylemez <e...@ertes.de> wrote:
> Kyle Murphy <orc...@gmail.com> wrote:
>
>> Remember that in most cases, once something is "inside" of a monad (IO
>> in this case), it's very difficult, impossible, to get it out again.
>
> I think, this is very misleading. Â You never get "out of a monad", you
> get "into" it, and you can do that whenever you want. Â Remember that the
> monadic world is inside of the pure world, not the pure world inside of
> the monadic world. Â In fact, the monadic world is part of it.
>
> The name bound by '<-' is something you can refer to in the pure world.
> There is nothing difficult about using the result of a monadic
> computation in the pure world. Â Just give it a name and refer to it, and
> that's it.
>
>
>> The do syntax just adds a convenient abstraction so that you don't
>> have to construct complex chains of >>= and >> operations by hand. In
>> our limited example this is fairly trivial, but consider something
>> like:
>>
>> main = do
>> Â something <- foo
>> Â blah <- bar something
>> Â moreblah <- baz something blah
>> Â putStrLn moreblah
>> Â putStrLn "really long chain now"
>
> Pretty straightforward:
>
> Â main =
> Â Â foo >>= \something ->
> Â Â bar something >>= \blah ->
> Â Â baz something blah >>= \moreblah ->
> Â Â putStrLn moreblah >>
> Â Â putStrLn "really long chain now"
>
>
>> which would be translated to:
>>
>> main = foo >>= (\something -> bar something >>= (\blah -> baz
>> something blah >>= (\moreblah -> putStrLn moreblah >> (putStrLn
>> "really long chain now"))))
>
> You could just as well write:
>
> Â main = do { something <- foo; blah <- bar something;
> Â Â moreblah <- baz something blah; putStrLn moreblah; putStrLn
> Â Â "really long chain now" }
>
> You are complicating things artifically. Â For example there is no reason
> to have all those parentheses, because (>>=) is associative by
> definition.
>
> The do-notation doesn't make nasty things nice. Â It makes nice things
> nicer. Â Don't be afraid to use raw monadic combinators, because
> sometimes they are much better:
>
> Â main = getArgs >>= mapM_ (readFile >=> putStr)
>
> Much more concise than:
>
> Â main = do
> Â Â files <- getArgs
> Â Â forM_ files $ \file -> do
> Â Â Â content <- readFile file
> Â Â Â putStr content
>
>
> Greets,
> Ertugrul
>
>
> --
> nightmare = unsafePerformIO (getWrongWife >>= sex)
> http://ertes.de/
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 26, Issue 30
*****************************************
