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 ===