How can eta-reduction of a well typed function result in a type error?

后端 未结 2 2093

I was playing around with van Laarhoven lenses and ran into a problem where the type-checker rejects the eta-reduced form of a well-typed function:

{-# LANGUAGE          


        
2条回答
  •  囚心锁ツ
    2021-02-19 02:27

    Actually it's quite straight-forward: GHC infers the types per expression, then starts to unify them across =. This works always fine when there are only rank-1-types around, because the most polymorphic one is chosen (that's well-defined); so any unification that's possible at all will succeed.

    But it will not choose a more general rank-2-type even if that would be possible, so getWith id is inferred to be ((a -> Const a a) -> c -> Const a c) -> (c -> a) rather than (forall f . Functor f => (a -> f a) -> c -> f c) -> (c -> a). I suppose if GHC did do such stuff, traditional rank-1 type inference wouldn't work at all anymore. Or it would just never terminate, because there doesn't exist one well-defined most polymorphic rank-n type.

    That doesn't explain why it can't see from get's signature that it needs to choose rank-2 here, but presumably there is a good reason for that as well.

提交回复
热议问题