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 <[EMAIL PROTECTED]> 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@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
