[core libraries] Re: Tightening up on inferred type signatures

[dm-list-haskell-libraries at scs.stanford.edu]

Edward Kmett <ekmett at gmail.com> writes:

> You can wind up in perfectly legitimate situations where the name for the
> type you are working with isn't in scope, but where you can write a
> combinator that would infer to have that type. I'd hate to lose that.
>
> It is admittedly of marginal utility at first glance, but there are some
> tricks that actually need it, and it can also arise if a type synonym
> expands to a type that isn't exported or brought into scope, so trying to
> push this line of reasoning too far I is possibly not too productive.

Good point.  In particular, it's not weird at all want to export type
synonyms on their own, particularly where ghost type parameters are used
to select between only a few cases.  Consider something like this
(inspired by postgresql-orm):

--
-- These are exported only by an internal module
--
data NormalRef = NormalRef
data UniqueRef = UniqueRef
newtype GeneralizedRef refType targetType = DBRef Int64

--
-- These are exported by the module everyone imports
--
type Ref = GeneralizedRef NormalRef
type RefUnique = GeneralizedRef UniqueRef

mkDBRef :: targetType -> Int64 -> GeneralizedRef refType targetType
mkDBRef = const DBRef

And now imagine somewhere in your code wanting to do something like
the following.

    mkModelRef = mkDBRef (undefined :: MyModel)

In fact, there may even be cases where the type is expressible with
synonyms but GHC is unlikely to figure it out.  (Or where multiple
synonyms are possible and it isn't clear which would be best, so :t
still prints the base type.)

In short, I'd be sad to see the strict version of this rule put into
place, particularly if it makes GHC stricter than Haskell2010 for code
that doesn't rely on language extensions.

David