Changes between Version 41 and Version 42 of Holes

Jul 1, 2012 4:48:54 PM (3 years ago)



  • Holes

    v41 v42  
    200200'''End of SPL''' 
     202'''holzensp''' I think the confusion comes from the notation used in the reports. The above examples do definitely typecheck (also when boo is defined with a signature as in SPL's example); the types are even inferred: 
     204import Control.Monad 
     206f x foo bar = do 
     207   y <- foo x 
     208   y `mplus` bar 
     210leads to the following GHCi-session 
     212[1 of 1] Compiling Main             ( Holes.hs, interpreted ) 
     213Ok, modules loaded: Main. 
     214*Main> :t f 
     215f :: MonadPlus m => t -> (t -> m (m b)) -> m b -> m b 
     218The confusion, I think, comes from the notation of the constraints as `MonadPlus m => m b` which usually signifies "this" `m` is bound here and thus not any other `m` from any other scope.  
     220If I may be so bold to suggest a different style of reporting; specifically one where holes are not reported on as they are encountered, but rather collected/grouped by commonality of their variables, e.g. 
     222f = do 
     223   x <- fmap fst $ runStateT _?prc _?st 
     224   y <- _?cnt x 
     225   z <- return (return 0 >>= _?indep) 
     226   return (y,z) 
     228Has holes with the following types (where variables are "quantified over the entire report," rather than locally): 
     230_?prc :: Monad m => StateT s m a 
     231_?st :: s 
     232_?cnt :: Monad m => a -> m b 
     233_?indep :: (Monad m', Num n) => n -> m' c 
     235This means that `_?prc`, `_?st` and `_?cnt` share type variables, whereas `_?indep` is independent of the others. I would suggest this style of reporting: 
     237Found holes with related type variables: s m a 
     238with constraints: Monad m 
     239typed as follows: 
     240prc :: StateT s m a 
     241st :: s 
     242cnt :: a -> m b 
     244Found hole 
     245indep :: (Monad m1, Num n) => n -> m1 t 
     247'''End of holzensp''' 
    202249=== Comparison ===