>>1
It's a device Haskell uses to, among other things, serialize computation. It's pretty nifty, but you can write working haskell code without knowing all the ins and outs if it hurts your brain too much. If you know a bit of Haskell already you could try reading http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html to see if it will help you understand them better.
Name:
Anonymous2009-11-21 15:26
>>1
It's any data type m of kind * -> * that possesses implemetations for these functions: return :: a -> m a
(>>=) :: m a -> (a -> m b) -> m b
that abide by these rules:
m >>= return ≡ m
return a >>= f ≡ f a
m >>= f >>= g ≡ m >>= (\a -> f a >>= g)
which basically say that return and >>= don't make any undue changes to the monad.
Name:
Anonymous2009-11-21 15:30
>>7
what the fuck is a kind and how do i make a function that works on kinds
Name:
Anonymous2009-11-21 15:31
explain the term in lisp term
Name:
Anonymous2009-11-21 15:33
>>8
A kind is the arity of a data type (how many parameters the type has), but I'm not sure what you mean by ``a function that works on kinds''.
In functional programming, a monad is a kind of abstract data type used to represent computations (instead of data in the domain model)
like lisp closures
Monads allow the programmer to chain actions together to build a pipeline, in which each action is decorated with additional processing rules provided by the monad.
So pretty much, they're closures of closures that provide functionality for you to manage the enclosed closure (as a FIFO right? it's probably two-way I guess, like a tconc list), which also make use of a protocol, the 'additional monad processing rules', which just adds some more features to whatever the hell haskell programmers are doing with them. It's manageable curry function. Seriously, I can write something like that in lisp in single fucking day.
Name:
Anonymous2009-11-21 15:48
>>11 Seriously, I can write something like that in lisp in single fucking day.
Yes, they're incredibly simple to write, and any Haskeller will be the first one to tell you that well any Haskeller except the ones who happen to be monad tutorial authors.
Name:
Anonymous2009-11-21 15:58
>>12
I think it may be because Haskellers focus far too much on the types rather than the idea. Reading through a Haskell Monad tutorial was painful, whereas the people who wrote 'Monads in X' (where X is a non-Haskell programming language) tended to focus on the concepts and were much more readable.
Name:
Anonymous2009-11-21 16:05
>>10
make me a function that takes a kind that is * -> * and returns a kind that is * -> * -> *.
Name:
Anonymous2009-11-21 16:11
>>13
I don't think all Haskellers are like that, just the ones who write essays, articles or tutorials about Haskell. They try to explain monads in very abstract terms, and then try to apply these abstract terms to concrete examples of monads. What they should do is to show a certain pattern of code that could benefit from a particular monadic abstraction, explain that abstraction in concrete terms related to that pattern of code and then make the abstract connection with other monadic abstractions. I.e. monads should be explained in a bottom-up way, and not top-down as usual.
Name:
Anonymous2009-11-21 16:20
>>14
Well, functions don't actually operate on kinds, but I supose it is possible to write a function that takes an object of an incomplete type and returns an object of another incomplete type, if that's what you mean.
Name:
Anonymous2009-11-21 16:22
what the fuck is a lisp
Name:
Anonymous2009-11-21 16:22
monad oriented programming is a crutch of pure functional programmers that can't implement proper solutions.