By the way, I thought it would be obvious, but a lot of people seem to
be missing the fact that I'm not (as Sean, I believe, isn't)
requesting limited support for 1 or 2 or 3 argument functions or
certain type classes to be applied to monads, or for certain
operations to defined on certain types. I know at least how to define
type classes and functions. If this is what I wanted I would probably
do it myself.
> I thought the easy answer would be to inject non-monadic values into the
> monad (assuming one already rejiggered things to do automatic lifting).
I don't know if this is the right way of looking at it. Do you have an
example?
My idea is that you should be able to have code like this:
-- (a)
m3 :: a -> m b
m6 = do
m1
m2
m3 (p1 (p2 p3 (p4 m4 p5)) p6)
m5
- where the m* values are functions returning monads and the p* values
are so-called "pure" functions, i.e. functions which don't take monad
values or return monad results (so currently the above code won't
type-check beacuse of m4) - but have it be interpreted as:
-- (b)
m3 :: a -> m b
m6 = do
m1
m2
v <- m4
m3 (p1 (p2 p3 (p4 v p5) p6)
m5
Note that in (a), "pure" values are never used where monads are asked
for, only the other way around.
I think that supporting syntax (a) for semantics (b) should be a
feature because: (1) it is (usually) obvious what (a) means; (2) it
eliminates the single-use variable 'v' - single-use variables like
this occur a lot in monadic Haskell code, and I think they make it
harder to read and write; (3) it would support the math-like syntax
that I presented in my original message.
It might be hard to modify the type checker to get it to work, but I
think it is possible, and I see no reason not to be as general as
possible.
Would it mean treating the 'Monad' class specially? Perhaps, but I
don't think this is a reason to avoid it. Further, it is likely that
whatever is done to extend the type checker could be given a general
interface, which Monad would simply take advantage of, using a
meta-declaration in the same spirit as "infixr" etc.
Also, I do not think that template haskell is powerful enough to
support this, but I'm willing to be proven wrong.
Frederik
--
http://ofb.net/~frederik/
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
