RE: Re[2]: 6.6 strikes me again :)

2006-09-22 Thread Simon Peyton-Jones
| class (Monad m) =  MRef m r | r-m, m-r
| class (Monad m) =  Stream m h | h-m
| newtype StringReader r  =  StringReader r
| instance (Monad m, MRef m r) =  Stream m (StringReader r)
| 
| coverage condition requires that monad type 'm' should occur in stream
| handle type 'StringReader r'. With MRef defined as bijective type
| function between m and r that is, in fact, true. may be compiler is
just not smart
| enough to figure this?

The coverage condition is certainly conservative -- there are cases
where nothing goes wrong if you drop it, and that's what
-fallow-undecidable-instances does.  The worst that can happen with
-fallow-undecidable-instances is that the type checker loops (and even
then it'll usually emit an error message); if the program typechecks
it'll run ok.

| is using -fallow-undecidable-instances safe in this situation?
| what of MRef fundeps, r-m or m-r, is really necessary in this case -
| i think it is r-m ?

I think you are right.

You could also try adding 'm' as a phantom type parameter to
StringrReader.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re[2]: 6.6 strikes me again :)

2006-09-20 Thread Bulat Ziganshin
Hello Simon,

Wednesday, September 20, 2006, 7:35:39 PM, you wrote:

 Quite right; that's just as specified.  The coverage condition is
 documented in the manual.  (GHC 6.4 and Hugs are too liberal, and
 thereby risk divergence during type checking.)   If you want this
 program to work, use -fallow-undecidable-instances

let's look at the slightly modified program:

class (Monad m) =  MRef m r | r-m, m-r
class (Monad m) =  Stream m h | h-m
newtype StringReader r  =  StringReader r
instance (Monad m, MRef m r) =  Stream m (StringReader r)

coverage condition requires that monad type 'm' should occur in stream
handle type 'StringReader r'. With MRef defined as bijective type
function between m and r that is, in fact, true. may be compiler is just not 
smart
enough to figure this?

is using -fallow-undecidable-instances safe in this situation?
what of MRef fundeps, r-m or m-r, is really necessary in this case -
i think it is r-m ?


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users