[Haskell-cafe] Re: Making monadic code more concise

2010-11-17 Thread oleg
Let me point out another concern with autolifting: it makes it easy to overlook sharing. In the pure world, sharing is unobservable; not so when effects are involved. Let me take the example using the code posted in your first message: t1 = let x = 1 + 2 in x + x The term t1 is polymorphic

[Haskell-cafe] Re: Making monadic code more concise

2010-11-17 Thread Ling Yang
Thank you for highlighting these problems; I should really test my own code more thoroughly. After reading these most recent examples, the translation to existing monads is definitely too neat, and a lot of semantics of the monad are 'defaulted' on. In particular for the probability monad examples

[Haskell-cafe] Re: Making monadic code more concise

2010-11-16 Thread oleg
Ling Yang wrote I think a good question as a starting point is whether it's possible to do this 'monadic instance transformation' for any typeclass, and whether or not we were lucky to have been able to instance Num so easily (as Num, Fractional can just be seen as algebras over some base

[Haskell-cafe] Re: Making monadic code more concise

2010-11-16 Thread Ling Yang
Thanks Oleg for the feedback. If I understand right, there is a hard (as in computability) limit for automatic instancing due to the general requirement of deriving functions off of the behavior of another. At this point, I wonder: How good are we at doing this? There's languages that reside in

Re: [Haskell-cafe] Re: Making monadic code more concise

2010-11-16 Thread Alexander Solla
On Nov 16, 2010, at 12:36 PM, Ling Yang wrote: Are only 'trivial' results possible, or that the incomputability problems are just moved into type space? That's typically the case, under Rice's theorem. A construct is derivable if it works for all cases (i.e., it's a free theorem), or