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

[Yitzchak Gale]

I heartily agree with everything Cale wrote
on this topic.

In addition, I hereby apologize to Claus for
being too lazy to participate in the survey.

Regards,
Yitz

Cale Gibbard wrote:
> 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
> >
>