[Haskell] Re: Mixing monadic and non-monadic functions

[Cale Gibbard]

Despite having a fairly mathematical background, I don't really care
for the proposed syntax.

myList :: [[Integer]]
myList = return [1,2,3,4]

Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either
interpretation is possible if there is automatic lifting about. If the
lifting only occurs when a type error would otherwise have happened,
then there will be cases where genuine type errors are happening and
being obscured by automatic lifting.

This basically takes a type error reported at compile time, which, in
the case where it would have been solved by lifting, is easily
resolved by simply adding a line to a do-block or by using liftM, and
turns it into a potential behavioural error which may only be detected
at runtime, and whose source in the code may not be so obvious (since
the lifting was unintentional in the first place).

Also, a class instance, say of Num for lists (treating them as
polynomials/power series) would suddenly turn one valid piece of code,
like [1,2,3] + [4,5,6] defined by automatic lifting, into a completely
different one, and suddenly silently introduce bugs into previously
written code in the module (perhaps written by another author who had
intended to use the automatic lifting).

I think that's reason enough to make people say what they mean in each
case. Automatic lifting is performed in mathematics because it is
assumed that the reader is an intelligent human who will be able to
infer quite reasonably what is meant in each (often somewhat
ambiguous) case. Haskell programs are not written only for humans, but
also for the Haskell compiler, which can't be expected to (and quite
possibly shouldn't try to) judge the intent of a piece of code.

 - Cale

On 09/09/05, Frederik Eaton <frederik at a5.repetae.net> wrote:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>