So can anybody tell me in a way one can understand it what a fucking monad does?
Name:
Anonymous2008-09-23 13:52
It's hides state because Haskellers are too afraid of side effects. It allows them to be hypocrites while they look the other way at what the language is really doing.
Name:
Anonymous2008-09-23 14:36
A nomad is like a package that hides something. You can stuff variables into it (HASKELL's way of assignment), you can open them, you can do something to the contents and repack.
I know my descriptions are (probably) non-enlightening but I intend to keep everything short; Google will help you find out more.
The only reason why monads have the appearance of complex wizardry is because it is a highly abstract concept and many descriptions use references to the math behind monads. If you're an experienced hacker that uses Haskell, you may have invented monads yourself. http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html
A monad is a kind of abstract data type (like a queue or a finite map) with two operations, bind and return, that are supposed to fulfill three mathematical properties. You will go a long way if you keep this in mind when thinking about monads.
Programmers often write code that can be described as "general computation blocks"; some data that has been processed is passed onto some more instructions that perform exactly the same process. Please don't confuse this (admittedly vague and useless) description with recursion or calling a function.
Monads allow programmers to describe "computational strategies" that will input data into the monad, perform the calculation which returns another monad. Writing code in this way allows the programmer to easily combine general computations in a purely functional manner. Another affect is that it allows programmers to "hide" a computation.
An example is a state monad which allows programmers to simulate 'imperative style variables' within a purely functional language.
Name:
Anonymous2008-09-23 20:16
Let's see if I got it right: monads are an ugly hack that's necessary mainly due to the stupid static type system, and also as a way to write (f (g (h (i x)))) as something like x → f → g → h → i?
No, it's because Haskell is a pure language without side-effects. There are non-pure languages with proper type systems.
Name:
Anonymous2008-09-23 20:27
Proper type system to me:
x.fuck()
Hello object referenced by x; lol, would you happen to have the word "fuck" in your dictionary by any chance? Cool, grab its reference. Hello object referenced by x.fuck; would you happen to be applicable? Awesome, now do it. (If any of this fails, raise DoNotWantException.)
Name:
Anonymous2008-09-23 20:30
without side-effects.
It's true…Haskell's stupid static type system prevents it from having any effect on the world whatsoever.
And you don't have to worry about fuck not being applicable or whatever because such a thing would raise an error at compile-time, you could even do the same for the fuck function by removing the third line.
Name:
Anonymous2008-09-23 20:40
>>16
Yes, but what if some other guy comes with a new class, Vagina, for which there's no implementation of x, yet the Penis one would work because Vagina objects can behave like Penises (yet they don't inherit from any common class or anything like that; maybe Vagina doesn't even know about Penis)? In a dictionary-based type system, the system couldn't give a fuck (no pun intended) about what you pass as long as it happens to have the dictionary keys you ask for.
>>18
No matter what, you'd still have to instruct the Vagina class to use Penis' implementation. A dictionary-based language is probably pretty dynamic and stuff, so you'd do it at object initialization time instead of compile-time as with Haskell.
Name:
Anonymous2008-09-23 21:02
>>20 No matter what, you'd still have to instruct the Vagina class to use Penis' implementation
Why? Penis could implement how to Move and Cum, so could Vagina, while being completely unrelated and inaccessible from each other. See example in FIOC:
class Penis (object):
def Fuck(self): #lol
return 'Oh'
class Vagina (object):
def Fuck(self):
return 'Ah'
Penis and Vagina could be defined in two completely unrelated files from two completely unrelated projects who happen to share a library that implements Stuff.
Name:
Anonymous2008-09-23 21:12
>>21 No matter what, you'd still have to instruct the Vagina class to use Penis' implementation Why?
If that's what you wanted to do, that is.
Penis and Vagina could be defined in two completely unrelated files from two completely unrelated projects who happen to share a library that implements Stuff.
Okay? Haskell could do that as well with typeclasses (oh man, I haven't used Haskell in months, excuse the made-up syntax):
[code]class Stuff x where
fuck x = raise NotImplementedException
data Penis deriving (Stuff)
instance Stuff Penis where
fuck x = "Oh"
data Vagina deriving (Stuff)
instance Stuff Penis where
fuck x = "Ah"
You never really went steady, but you'd run into her from time to
time while knocking around in disreputable joints, usually late at
night, every several months or so. She looked so hot, so sleek, so
sexy, so expressive, so exotic. You'd end up back at her place and
the night would just... take off. A complete blur of hot, sweaty,
feverish, delirious, fumbling passion. You'd do things to each
other... you'd do things to her, she'd do things to you... things
that you're not even sure have names, that you're pretty sure are
illegal almost anywhere. Even her kinks have kinks --- and after one
of these nights, you'd realize that you yourself had a lot more kinks
than you. And it wasn't just physical, it was --- cerebral.
Ethereal. Transcendent. But it would all whiz by in a blur, and by
morning you'd find yourself lightheaded, a bit confused, and
stumbling homeward to your regular gal.
Over the next few days and weeks you'd find yourself occasionally
drifting away, thinking about her. Haskell. You'd be there, banging
away at your regular girl, and find yourself thinking "you know, if I
was with Haskell, I'd be doing this completely differently." You'd
think "I could be doing so much bigger and better stuff with
Haskell." Now, your regular girl, she's not as exotic as Haskell.
Pretty, maybe, if you're lucky. (Perhaps your regular girlfriend's
name is Python. ;-) But not nearly as --- weird. Wild. Cool.
Exciting. Don't get me wrong --- your girl, she's wonderful. You've
got a wonderful relationship. She's --- comfortable. You can bang
away at her all day and night. She's accommodating. Easy going.
You work well together. But --- confidentially --- she's, well,
maybe just a little bit boring. You'd catch yourself thinking these
things, and the guilty pangs would get to you... You'd quash the
thoughts, buckle down, and get back to banging away. Comfortable...
there's a lot to be said for that, ya know? Comfortable... just
keep telling yourself that.
Months would go by. Late some night you'd find yourself out,
disreputable places again. Maybe that hacker bar, LtU. Somebody'd
slip you an URL for some renegade paper, you know, one of *those*
papers. You'd run into Haskell again. And the whole thing starts over.
Eventually, you're going to get the ultimatum. Haskell's ultimately
just like any other girl on some level; she needs commitment.
Eventually, after one night of wild, feverish, kinky, abstract
passion, she's going to say to you: "All these times, and you don't
understand me at all! You know, you're going to have to get serious,
mister! I've got needs, too. You're going to have to get serious
about my monads, or that's the last time you're going to play with
them! Got it?"
...and then, you've got to make The Choice.
Chances are, you're going to go back to your regular gal. Haskell's
just too much for any one man, probably. She leaves a trail of
broken, brainy, embittered PhDs and former programmers behind her.
She ruins you for the RealWorld. You can ride a while, but you
probably can't go the distance with her. Go back to your regular gal
and try not to think too much about what you've seen. Done. Felt.
Thought.
Maybe you can salvage a little happiness; but it'll be hard. After
all... you've tasted Haskell.
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
oh my god you are all idiots
Name:
Anonymous2008-09-24 9:44
>>26
whoever wrote that is a tragic shell of a man...
Name:
Anonymous2008-09-24 14:21
>>31
heh yeah, horrible how fucked up geeks can get
Name:
Anonymous2008-09-24 14:51
I came....
Name:
Anonymous2008-09-24 18:37
>>22
So can Java. But this means you have to define a class or interface with placeholder methods and properties beforehand, and that this class must be known to all three parts - the Penis, the Vagina, and the guy calling fuck. Python doesn't require this; the guy who writes Penis and the guy who calls fuck may not know each other besides the fact they can fuck, and may not know Vagina at all, because Vagina could be developed somewhere else, some other time, and it could just happen to be useful to replace a Penis in a future version of the fucker guy's program. Interfaces, called protocols in Python jargon, are just documentation of guidelines in order to make objects that feel alike.
All the manuals on haskell monads suck - including yaht. Some tell shit, some claim stuff which has nothing to do with monads and most of them are written with so much complex shittalk or can't get it to the point that they are completely unusable.
As long as they can't write a single proper tutorial about monads, im just gonna stay far away from haskell. Better: they should just scrape monads and replace it with something which doesn't sound like ancient voodoo magic.
Name:
Anonymous2008-09-25 15:01
We conjure the spirits of the computer with our voodoo spells.
Name:
Anonymous2008-09-25 18:25
>>40
There's nothing to it, really. Monads allow you to express a purely functional computation while keeping some aspect of that computation hidden or implicit. For example, if you wanted to write a function that returns a list of n random numbers using the function random :: (RandomGen g, Random a) => g -> (a, g), you'd write something like this:
nRandoms n gen
| n <= 0 = ([], gen)
| otherwise = (r:rs, gen'')
where
(r, gen') = random gen
(rs, gen'') = nRandoms (n - 1) gen'
See how you have to explicitly handle the "state changes" of the random generator by passing it around? Well, if you turn the random function into a State monad:
randomS :: (RandomGen g, Random a) => State g a
randomS = State random
then you can write nRandoms like this:
nRandomsS n
| n <= 0 = return []
| otherwise = liftM2 (:) randomS (nRandomsS (n - 1))
nRandoms n gen = runState (nRandomsS n) gen
or even like this:
nRandoms n gen = runState (replicateM n randomS) gen
What this particular monad, the State monad, does is handle the state changes implicitly, so you don't have to worry about it. Here's (part of) the definition of that monad, see how simple it is:
newtype State s a = State { runState :: s -> (a, s) }
instance Monad (State s) where
return a = State $ \s -> (a, s)
m >>= k = State $ \s -> let (a, s') = runState m s
in runState (k a) s'
It is perfectly fine to write Haskell code without ever touching a monad (let's forget about the list and IO monads for now). However, as time progresses and experience accumulates, people inadvertently write Haskell code that fits the definition of the Haskell monad; they create and use their own monads and find the concept monads are simpler than first expected when someone points it out to them. This is what happened to me.
For me, monads are easy. I didn't study any math greater than high school level math. I failed to understand the tutorials on Haskell monads before I realised how powerful and elegant they are when a friend pointed out that I was writing and using my own monads. I found that some other people felt the same way about monads - the tutorials about monads are hard and confusing. This led me to conclude that monads are easy - explaining monads to the non-enlightened is not.
So I guess my point is to keep hacking in Haskell without bothering about monads. However, be aware that you're missing out on a very powerful tool.
Name:
Anonymous2008-09-25 20:49
>>42 this particular monad,
Nice effort, and the last bit almost makes sense, but you didn't really explain monads. I'm tired of seeing discussions of a single instance, when as a whole they're apparently
1) not particularly related
2) wired into the compiler as special cases
3) able to segfault if used in any construct other than the ones handed down by ``SPJ'' Peyote-Joints himself.
Seriously, where does List get off being in the same category as IO? Do the magicks attached to those have anything to do with being a monad? What does it even mean for something to be a monad?
Name:
Anonymous2008-09-25 21:09
>>45
1) They aren't related.
2) If you're talking about the do notation, that's just syntactic sugar.
3) That didn't make sense.
A monad is just a data type that implements these functions:
(>>=) :: Monad m => m a -> (a -> m b) -> m b
(>>) :: Monad m => m a -> m b
return :: Monad m => a -> m a
If you're looking for it to mean more than that, you're either trolling, crazy, or trying to drive yourself crazy.
Oh yeah, and they also must obey these laws:
return a >>= f == f a
m >>= return == m
(m >>= f) >>= g == m >>= (\a -> f a >>= g)
Name:
Anonymous2008-09-25 21:21
>>45
If you think of the monad as a "computation strategy", you'll find that each different monad implements a different strategy. This explains why each monad is not really related.
>>46
2) I'm talking about how monads seem to be a gathering point for strange behaviors that (presumably) can't be implemented in the language itself, and whatever Haskell code may represent them is replaced by internal functions at compile time.
3) That's been my experience when a program I'm trying to write gets too tangled among the standard monads. Even when GHC accepts the code, the runtime crashes on it.
If you're looking for it to mean more than that, you're either trolling, crazy, or trying to drive yourself crazy.
Or I've read basically anything ever written promoting/teaching Haskell, wherein so-called “monadic behavior” is touted as a major defining aspect of the language (rather than “hey I thought of a way to rearrange that function”) and the monads themselves are giant shadowy beasts of which we must never speak.
>>42
Thank you for your explanation, but i know that already. The reason why i still don't use haskell is that monads are said to do a lot more than they really do. Especially because they are called Monads and that they are used to encapsulate side effects. Call them wrappers, containers, templates, whatnot, but the name monads in itself has no apparent meaning and should go away.
And about how they encapsulate side effects (As far as i understand). Monads either force the compiler to execute a function with side effects exactly the number of times we want it and no known (or UNKNOWN) optimization can change the order or number of times or they are broken. But i could not find any article describing which laws of mathematics would enforce monads to act how people claim they do. And we talk about laws which can be enforced in a pure functional language using only the core concepts which weren't written to explicitly support monads, because the developers of haskell claim, that they didn't need to add special support for them.
If i think about it, we get several possible cases:
1. There are some rules which make monads possible in the most efficient manner without bad effects on the other parts of haskell in terms of run speed, stability and usability.
2. it is not possible to efficiently optimize haskell code, because the used laws are to strict, else they could not support monads and hence functions with side effects.
3. Monads are broken.
4. Haskell is not a pure functional language.
Name:
Anonymous2008-09-25 23:56
I'd jizzim all over Haskell's pretty little face.
Name:
Anonymous2008-09-25 23:57
>>50
forgot
5. Haskell is broken
6. Haskell has special support for Monads
the cases are all about side effects in haskell
Name:
Anonymous2008-09-26 0:39
and people still drink the Kool-Aid and claim that Haskell is a pure functional language.
Name:
Anonymous2008-09-26 1:12
>>50 Call them wrappers, containers, templates, whatnot, but the name monads in itself has no apparent meaning and should go away.
SPJ did not invent the term ``monad''. Your shitty vocabulary is no reflection on Haskell.
Name:
Anonymous2008-09-26 1:15
>>53
It is purely functional, but it is possible to write functions in C that aren't pure, but seem pure to the user.
In reality, no language can be absolutely purely functional, because then nothing would be happen. As SPJ has said in his slides, the goal is to merge the useful, dangerous languages which always allow side effects with the safe, useless ones which don't, so that we reach a sort of programming language nirvana.
Name:
Anonymous2008-09-26 1:20
>>50
Except it's not a function being executed N times and having side effects, it's a function being composed against itself to the Nth degree and having cumulative effects on a value invisibly threaded through the whole sequence.
Name:
Anonymous2008-09-26 2:07
>>54
right, some mathematican invented that shitty name and some other shitheads thought it was a good idea to rename old concepts (encapsulation) in programming with it, instead of using a name which describes what monads are good for. I wonder why some people try so hard to find creative names, which fit the topic.
>>56
>Except it's not a function being executed N times and having side effects, it's a function being composed against itself to the Nth degree and having cumulative effects on a value invisibly threaded through the whole sequence.
Which sounds good for me, as long as nobody wants to tell me now about how we put the world state into the monad or need to compute an actual value in haskell itself besides executing the function to give it some unique id. Last problem for me in haskell solved, i should be happy.
As far as i understand it now is, that the haskell compiler can't look into the functions written in c and thus does not know what they will return with which input value, thus the created program has to execute them every time. Monads and similar stuff (Arrows) just make sure, that we use a return value only one time.
Only problem is a runtime environment, which could predict from the last input values the output values of a function and replace its call with the result without executing anything.
Name:
Anonymous2008-09-26 8:03
>>57
Let's implement side effects in Haskell without using Monads. Haskell is a pure language, so all side effects must be explicit. To do that we first define a datatype data World = World ... World contains all the state of the runtime environment. Now if we want to write a function that modifies this state, we must pass the state to the function and then it returns a value and a new state. So we would define getChar as getChar :: World -> (Char, World)
and putChar as putChar :: World -> ((), World) putChar doesn't have any return value so we return () which is just the same as void in C.
Now we want to use these function to write a function cat, which copies it input to the output. cat has side effects so it gets a state as a paramater and returns () and a new state. cat :: World -> ((), World)
cat s0 = let (x, s1) = getChar s0
in if x == EOF
then ((), s1)
else let (y, s2) = putChar s1
in cat s2
You can probably see that this explicit passing of state can get ugly real quick. Monads allow us to hide this. We define a datatype IO as data IO a = IO (World -> (a, World))
which is any function which has a side effect and returns a value of type a. So now our getChar and putChar are defined as getChar :: IO Char
putChar :: IO ()
To make IO into a Monad we must implement the functions of >>45. instance Monad (IO a) where
IO m >>= f = IO (\s0 -> let (x, s1) = m s0
IO m' = f x
in m' s1)
IO m >> IO m' = IO (\s0 -> let (x, s1) = m s0
in m' s1)
return x = IO (\s0 -> (x, s0))
Now we can write our cat function as cat :: IO ()
cat = getChar >>= (\x -> if x == EOF
then return ()
else putChar x >> cat)
Or using the do-notation as syntactic sugar cat :: IO ()
cat = do x <- getChar
if x == EOF
then return ()
else do putChar
cat
>>49
2) There's no substitution, it's all Haskell.
3) I've never seen anything like that happen. An example would be great.
>>49,57
You know, if you look at ther source code of the monads, all your doubts will vanish.
Name:
Anonymous2008-09-26 11:59
>>61
>You know, if you look at ther source code of the monads, all your doubts will vanish.
I did that and yes, IO Monad uses RealWorld. But until i analyze every element of the source, i'll stay with the explanation in >>56 , which catches enough for me.
Name:
Anonymous2008-09-26 12:15
I'd like to look at the source code of Leah Culver's monads, if you know what I mean.
>>56
Do you think so much complexity is really worth it, when we could be using a language as simple as, say, Scheme?
Name:
Anonymous2008-09-26 14:03
>>66
It's not actually complex, and you have to try the language yourself to really answer that question. My personal opinion, though, is that Haskell is indeed very much worth itsage.
>>66
Putting up with the endless contortions of Haskell's type system in search of a meaningless standard of purity doesn't make a lot of sense, but locking yourself in a small white room made of fuzzy parentheses isn't productive either. I stick to practical languages; preferably those made for extraction and/or reporting.
Name:
Anonymous2008-09-26 14:22
>>58 Haskell is a pure language, so all side effects must be explicit.
Proof that all Haskell users are on drugs.
Name:
Anonymous2008-09-26 14:24
>>69
I don't feel a complex type system is the pinnacle of purity. To me, dynamic typing feels far nicer.
Name:
Anonymous2008-09-26 14:42
>>71
How is Haskells type system complex? I think it's pretty simple and straightforward and because functions and types work together in a natural way, you can write concise programs.
>>70
No, just that they care more about correct program behavior and proofs and don't want their computers fucked up because of some nasty memory bug.
Name:
Anonymous2008-09-26 14:53
>>72 No, just that they care more about correct program behavior and proofs and don't want their computers fucked up because of some nasty memory bug.
But where are these awesome Haskell programs that perform correctly and solve all the world's problems? It just happens to be that I stopped using the only Haskell program I've ever found even remotely useful, darcs, after I found out that it systematically chokes on even the most elementary operations*.
* Yes, it didn't fuck up my computer because of some nasty memory bug, but I favour programs that actually do what I want, when I want.
>>80
I wrote a stripped down diff clone in Haskell. No rudimentary libraries missing.
Name:
Anonymous2008-09-26 16:34
>>83
Wow. That sure is a huge improvement over the C version that constantly fucks up my computers because of some nasty memory bug. Could you share it?