[16:40:15] ihope/ sum [1..sum [1..8]]
[16:40:17] lambdabot 666
[16:40:27] GeniXPro/ nice
[16:40:40] GeniXPro/ You created the best number!
[16:40:44] GeniXPro/ beast*
[16:40:58] ihope/ What a typo.
[16:43:38] ihope/ "This calls for wisdom. If anyone has insight, let him calculate the number of the beast, for it is man's number. His number is 666."
We first see
What bind does is to take a container of type (m a) and a function of type (a -> m b). It first maps the function over the container, (which would give an m (m b)) and then applies join to the result to get a container of type (m b).
But then we see
Joining is equivalent to binding a container with the identity map. This is indeed still called join in Haskell:
So then the question becomes: if bind uses join and join uses bind, then we have a serious circularity issue...
From the ocaml book we have the following
Certain algorithms are easier to write in this (imperative) programming style. Take for instance the computation of the product of two matrices. Even though it is certainly possible to translate it into a purely functional version, in which lists replace vectors, this is neither natural nor efficient compared to an imperative version.
I was reading Cale Gibbard's Monads as Containers and thought "now this is what I learned Haskell for" and then I began to wonder about Ocaml and monads, which led me to google which led me to this post on non-deterministic monad of streams which the author says "cannot be (naively) done in either Prolog or in Haskell's
|MonadPlus monad, both of which would go into an infinite loop on this example."
[19:33:05] /Cale/ But in FP, things are usually sort of 'dual' to OO in a strange way. Data is inextensible, but the operations on it are very extensible, which is sort of the reverse of the situation in OO-land.
[19:26:57] /Cale/ loufoque: another thing is that it's just
fun to program in Haskell -- you don't feel so much like
you're writing boilerplate code all the time, and if it
compiles, it usually works, since the typesystem catches
80 or 90 percent of all the stupid mistakes which the
compilers in other languages wouldn't.
Because (++) has time complexity linear in the length of its left argument, showTree is potentially quadratic in the size of the tree.
in response to this code:
showTree (Leaf x) = show x
showTree (Branch l r) = "<" ++ showTree l ++ "|" ++ showTree r ++ ">"
So this brings up two questions:
- Why does
(++)have time complexity linear in the length of its left argument?
- Why is showTree potentially quadratic in the size of the tree?
- For a function
fn (x:xs) ...what happens if it is called like this
- An error
- A convenient way to alias a type is how?
type String = [Char]
- A Haskell paste page which syntax highlights Haskell code. Using paste.lisp.org is not a good idea because people don't respond to paste questions listed there