Is just referred to as an algebraic type. Is the SML code really a monad? Is the Haskell monad still an algebraic type? All the tutorials on Haskell monads seem to introduce simple monads, like the list monad, that can be adequately modelled in SML using an algebraic data type. Why make things so complicated?

No answer here. I’d just like to remark that if some kind computer person would tell me what the two quoted lines of code, so to speak, “mean,” and how they mean it, I’d be grateful. I like to know this kind of stuff.

They both do the same thing, more or less. They create a new type that’s polymorphic in all types (the a and 'a, read alpha, are type variables). The type can either take the value Nothing (or NOTHING) or it can take the value (Just 5, for instance, or SOMETHING 5).

Possibly. They’re more like enumerations on steroids, where not only can the enumeration denote a label, but the label can carry around with it a value of any type.

For example:

fun position' [] element counter = NOTHING
| position' (h::t) element counter =
if h = element then SOME counter else (position' t element (counter + 1))
fun position list element =
position' list element 0

Trying to find the position of 2 in [1, 2, 3] will give “SOME 2” whilst trying to find the position of 5 will yield “NOTHING”.

Monads and algebraic types and just two different names for the same semantic construct, which comes from the category theory underlying all functional programming languases.

Ahh, thanks. I knew monads came from category theory, but I had always been told that they didn’t bear much relation to category theoretic monads other than the name. Do you have any decent links that explains the maths behind this?

Mark Chu-Carroll at Good Math, Bad Math has a bunch of posts about category theory from a computer science viewpoint, as well as a (half-finished) series on Haskell in particular. One of the semi-regular commenters there also seems to know which way is up, and fills in some of the math Mark misses.