RecordClass.elm

-- interface is a more familiar name for the intention of the construct
type alias Append a rest = { rest | append : a -> a -> a}


-- implement is a more familiar name
stringAppend rest = {rest | append = \x y -> x ++ y}

-- this is Monoid
type alias AppendWithId a rest = Append a {rest | id : a}
--                ^ 1 potential superclass


appendWithIdString rest = {rest | id = ""}

type alias Eq a rest =
    {rest | eq : a -> a -> Bool}

neq : Eq a rest -> a -> a -> Bool
neq inst x y = not <| inst.eq x y


concat : AppendWithId a rest -> List a -> a
concat inst list =
    case list of
        (x::xs) ->
            inst.append x (concat inst xs)

        [] ->
            inst.id


foo : Append a rest -> Eq a rest -> a -> a -> a
foo ainst einst x y =
    if neq einst x y then
        ainst.append x y
    else
        x

Monads for monads' sake don't count for anything. See Joey's comment: what can't you build? How is your code adversely affected? Granted, my example isn't really concrete either.

I guess I feel differently, in that monads for monads sake is useful. One of the appeals of working in a functional languages is the many problems are solved for you by useful functions, and reduce cognitive overhead by using simple polymorphic abstractions. sequence is a great example, if we had sequence I would not have to write it myself so frequently and for different types. I can do it because I understand this one very well, but I'd not claim that for all the functions I regularly use, nor would I want to demand that level of understanding from others, simply to take advantage of useful abstractions like sequence or andMap.

I guess I feel differently, in that monads for monads sake is useful.

This is a complaint as old as Elm itself. I would recommend reading this post from Evan on this subject, and maybe some surrounding context in that thread.