-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No type inference in some cases #31
Comments
@k0ral the issue regarding the extra type annotations manifests itself in simpler examples as well. eg. import qualified Control.Monad.Reader as CR
import Control.Eff.Reader.Lazy
-- the below compiles as expected
i1 :: CR.Reader Int Bool
i1 = do
_ <- CR.ask
return True
-- h1 doesn't compile
h1 :: (Member (LazyR.Reader Int) r) => Eff r Bool
h1 = do
_ <- LazyR.ask
return True the above is a tradeoff of extensible-effects. specifically (and as is mentioned at the end of section 4.1 in the paper), the interface which is exposed in this library is one which favours extensibility at the cost of some more type annotations. take into consideration what the type annotation of that being said, it is entirely possible to give up this extensibility and recover the benefit of having fewer type annotations. see ExtMTL.hs for examples. if you would like to see that functionality exposed and supported as part of the extensible-effects library, please open another issue or reopen this one. and, apologies for the delay in getting back. |
I'm seeing a similar problem, perhaps you could clarify. Here's the final part of some E-E testing I'm doing: data Dilithium = Dilithium
-- | Why can't the type of the State value be inferred?
engage :: (Member (State [Dilithium]) r, Member (Exc String) r) => Eff r ()
engage = get >>= \(ds :: [Dilithium]) -> do
if length ds < 5
then throwExc "We're short on Dilithium, Cap'n!"
else modify (drop 5 :: [Dilithium] -> [Dilithium])
loadCrystals :: Member (State [Dilithium]) r => [Dilithium] -> Eff r ()
loadCrystals = modify . (++)
captLog :: Member (Writer String) r => String -> Eff r ()
captLog s = tell $ "Captain's Log: " ++ s
voyage :: ( Member (Writer String) r
, Member (State [Dilithium]) r
, Member (Exc String) r
) => Eff r ()
voyage = do
captLog "Time for a cosmic adventure!"
captLog "Need to fill the tanks."
loadCrystals . take 18 $ repeat Dilithium
captLog "Engage!"
engage >> engage >> engage >> engage
captLog "We made it to our destination."
-- | Doesn't compile.
vt :: Either String ()
vt = snd $ run $ evalState [] $ runMonoidWriter $ runExc voyage
What exactly does this error mean? |
This seems to have fixed it: vt :: Either String ()
vt = snd $ run $ evalState ([] :: [Dilithium]) $ runWriter (++) "" $ runExc voyage |
the type of state value can't be inferred because of the open world On Sat, May 16, 2015, 05:01 Colin Woodbury [email protected] wrote:
|
When using ext-eff, I find I have to add type annotations more than I'd like
For example (with GHC 7.8.4, ext-eff 1.9.0.1):
It looks to me that the
g1
implementation has all the necessary information for GHC to infer that I'mask
ing for anInt
. Strangely enough, type annotatingask
doesn't work either.I'm not sure whether this is an issue in extensible-effects or if it is inherent to GHC's type inference. Can you assist ?
For information, the build errors are the following:
g1
:g2
:The text was updated successfully, but these errors were encountered: