However, you'd really want some static type checking preventing you from calling getNextParameter too many times, while allowing you to but elements of different types in the stack.

You can perhaps index a state monad-like structure by the type of call stack it expects. For example, "ST (Int, (Double, (Char, ()))) Int" could be the encoding of a function Int -> Double -> Char -> Int, and the getNextParameter method might have type:

getNextParameter :: (a -> ST as b) -> ST (a , as) b

But I am not sure whether it is still a monad, though...

http://blog.sigfpe.com/2007/04/trivial-monad.html

(Reply: yeah, looks like it does formatting, I thought I'd turned that off for comments, sigh. I've edited, adding some spacing which seems to work around that).

Reader a = (a ->)

So a curried multi-parameter function can be considered as a composition of many Readers.

Reader a . Reader b . Reader c == (a ->) . (b ->) . (c ->)

A monad is a functor equipped with two natural transformations that follow certain laws. So this composition is actually a composition of functors. Another way of looking at it is that we're wrapping many functors around the same holes, so we can rewrite the composition as (a -> b -> c -> -) using dash as our metasyntactic variable, as is common in category theory. Similarly we can think of ([-] . [-] . [-]) which can also be written as [[[-]]].

For the [[[-]]] example, one of the monad laws allows us to collapse multiple layers into a single layer so every [[[X]]] can be mapped to some [[X]] and every [[X]] can be mapped to some [X], both with certain properties of "preserving structure". Now, in the case of Reader we should consider what that means. Using join requires that all the layers are the same (e.g. (a->).(a->)), but the join of the Reader monad collapses that so everyone reads from the same a (it maps every (a->a-> X) to some (a-> X)), which isn't what we want for currying.

But there is a different way that we can "collapse" the composition of different Reader monads. Namely, we can find a mapping from (a->).(b->).(c->) to (a * b * c ->) aka ((a,b,c) ->). This general process is what uncurrying is about, and the dual is currying.

So, to answer your question, no currying does not form a monad--- at least not directly. However, the type constructor Reader is itself a functor as well, not just (Reader X) for all X. So if we look at (->) as a functor, then the composition (a->).(b->).(c->) is remarkably similar to the expression [a]++[b]++[c] which can be reduced to [a,b,c] in analogue with (a * b * c->). Note particularly the two different operators in flight for both examples.

The natural isomorphism between (a->).(b->) and (a * b->) is quite different from the natural transformation from F.F to F. For one, the former is an isomorphism so we can rewrite in either direction. Other details have to do with the fact that (->) forms a category (with id and (.)) and that it doesn't form a monoid (with the same) except in the restricted case of endomorphisms (X->X).

For un/currying to be possible the category for (->) must be cartesian closed, meaning it has all products and exponentials as objects. Most of the common categories are CCC, but not all are.

Prelude Control.Applicative> import Control.Applicative

Prelude Control.Applicative> pure (+) Just 3 Just 4

Just 7

Prelude Control.Applicative> import Control.Applicative Prelude Control.Applicative> pure (+) Just 3 Just 4 Just 7

I used the MayBe Monad but you could create your own type that just boxes a value and pure could be simply something like id.