haskal nomad?

Modelling monads with a typeclass is stupid. There isn't one true monad for a given type. It makes no sense that when you use bind with lists you automatically get concatmap.

monads
u mena gonads
kekekekekekekeke

You can instantiate Monad for lists in whatever way you please.

>>3
But only in one way (and there's more than one possible monad with list).

The Forced Big Designing Up Front

If you need multiple monad implementations for lists, you can do something like this:

data D a = A [a] | B [a] | C [a]

instance Monad D where
A xs >>= f = ...
B xs >>= f = ...
C xs >>= f = ...
...

I agree, though, it is ugly.

>>6
Who'd have thunk that a syntax-heavy strongly- and statically-typed language would be ugly? Wow!

thunk
This expression is of type noun but an expression of type verb was expected.

>>7
syntax-heavy
Not really. Assuming that you're talking about how many operators Haskell has, they're just regular infix functions that can be user-defined.
strongly-
Weak typing is shit.
and statically-typed
I don't think it's a problem with static typing in general, it's just something Haskell's type system wasn't designed to be able to do easily. Besides, how would you do this in a dynamically-typed language?

>>8
thunk \ˈthəŋk\
dialect past and past participle of ^_THINK

>>9
Besides, how would you do this in a dynamically-typed language?
You can always tell when someone is out of their depth when they shift the burden of proof.

You've got a problem with Ron Paul? Then how do you explain Obama's actions with respect to X, Y, and Z?

>>11
I don't mean it that way, I'm just wondering what you think would be a better way to do it. It seems like for a decent implementation of monads with several different types depending on which monad is it, you'd basically need to write your own type system (Greenspun's tenth rule in reverse). And I'm not saying that Haskell is perfect.

>>12
Please don't take anything here seriously!

maskal no umad?

>>12

$ ghci
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude> ["Abc", 123]

<interactive>:1:8:
    No instance for (Num [Char])
      arising from the literal `123' at <interactive>:1:8-10
    Possible fix: add an instance declaration for (Num [Char])
    In the expression: 123
    In the expression: ["Abc", 123]
    In the definition of `it': it = ["Abc", 123]
Prelude>

>>4
So? With newtype you can have as many lists as you wish. Plus there are overlapping instances.

>>15
Do you even understand what this discussion is about?

>>17
No. I don't understand the notion of "monoid from category of endofunctors".

So. We introduce the notion of category. This kind of very abstract entity (even more abstract than a set). In a sense, the category consists of two things: a set of objects and a set of morphisms. With respect to these objects and morphisms given some axioms there. They imply that the category can be represented as a directed graph, where vertices - is an object category, and the arch - a morphisms. It is essential that a morphism as in the arc of the graph, there is a "beginning" and "end" (called the domain name and code), and are objects of the same category. Domain and the code of the morphism (beginning and end of the arc of the graph) can match. Such a morphism is called an endomorphism.

A more interesting example for us: the category Hask. Here objects - are data types that are possible in language Haskell, and morphisms - features of Haskell.

>>18
Back to lambda-the-ultimate dot org, please!

>>16
Then you have to choose a type based on what monad you want to use. Seems awkward. Also you still can't use different monads with the same type.

Of course the whole idea of overloading bind and return operators is flawed (not for practical use but for modelling monads).

>>19
So, isn't an endomorphism just the identity morphism? Or there can be more morphisms from X to X for some X (e.g. an endofunctor F : X -> X which can be any morphism f : a -> b for some a, b in X)?

>>20
That's not exactly an insult.

>>23
It's not intended to be one. It's a plea to return from whence one originated.

Haskell is constipated shit.

>>11
http://richhickey.github.com/clojure-contrib/monads-api.html

>>26
Clojure is shit, Rich.

>>27
Rick is Clojure, shit.