Better document TypeRep patterns
ClosedPublic

Authored by bgamari on Sep 11 2017, 8:36 AM.

Details

Summary

As pointed out in Trac #14199 these are rather non-trivial; extra documentation is
in order.

[skip ci]

Test Plan

Read it

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
bgamari created this revision.Sep 11 2017, 8:36 AM
dfeuer requested changes to this revision.Sep 11 2017, 8:42 AM
dfeuer added inline comments.
libraries/base/Data/Typeable/Internal.hs
281

Will App match a function type? If not, or if not always, that needs to be documented explicitly here.

314

Since the Con' pattern seems most complex, could you add an additional example with more moving parts? How complex can it get?

This revision now requires changes to proceed.Sep 11 2017, 8:42 AM
bgamari updated this revision to Diff 13825.Sep 11 2017, 1:06 PM
bgamari edited edge metadata.
bgamari marked an inline comment as done.

Address comments

libraries/base/Data/Typeable/Internal.hs
314

I'm not sure I understand the request here. What other moving parts are there?

For the record,

libraries/base/Data/Typeable/Internal.hs
281

Note that this is a bit of a compromise. If Typeable were to reflect GHC's internal type language then we would be able to decompose a function type into two applications. However, we unfortunately have no way of talking about talking about (->) applied to a particular set of kind arguments (as its arguments are of Inferred visibility).

This revision was automatically updated to reflect the committed changes.
goldfire added inline comments.
libraries/base/Data/Typeable/Internal.hs
281

I'm confused by Ben's last comment here. Why should it matter whether the arguments are Inferred? And, besides, without visible type application in types, there is no difference between Specified and Inferred here.

bgamari added inline comments.Sep 14 2017, 11:14 AM
libraries/base/Data/Typeable/Internal.hs
281
And, besides, without visible type application in types, there is no difference between Specified and Inferred here.

Yes, I suppose this is the relevant point here. The fact that we don't have VTA on types means that it is impossible to write a particular instantiation of (->). However, the fact that the runtime rep arguments are Inferred would mean that we still wouldn't be able to write the type, even if we did have VTA.

goldfire added inline comments.Sep 14 2017, 11:24 AM
libraries/base/Data/Typeable/Internal.hs
281

I guess my confusion is this: how does the Specified/Inferred flag affect TypeReps? I would expect that TypeRep design/behavior to be totally independent of this flag.

bgamari added inline comments.Sep 14 2017, 2:18 PM
libraries/base/Data/Typeable/Internal.hs
281

Imagine you have a typerep like,

rep :: TypeRep (Int# -> Char)

Now imagine that you want a function that will give you the TypeRep of the arrow in that type. The type of this function would need to be something like,

giveMeTheArrow :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) 
                         (a :: TYPE r1) (b :: TYPE r2).
                  TypeRep (a -> b) -> TypeRep ((->) @r1 @r2)

However, we have no way of writing the type (->) @r1 @r2 in Haskell today, unfortunately.

goldfire added inline comments.Sep 14 2017, 2:49 PM
libraries/base/Data/Typeable/Internal.hs
281

What about

giveMeTheArrow :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2).
  TypeRep (a -> b) -> TypeRep ((->) :: TYPE r1 -> TYPE r2 -> Type)

?

bgamari added inline comments.Sep 14 2017, 6:18 PM
libraries/base/Data/Typeable/Internal.hs
281

Well, don't I feel silly?

Yes, that indeed would work. D3969 is the beginning of an attempt at fixing this infelicity. Unfortunately the kind errors got a bit much for my brain at this hour, so I'm going to put it aside for a bit.

goldfire added inline comments.Sep 14 2017, 9:30 PM
libraries/base/Data/Typeable/Internal.hs
281

Happy to help brainstorm if that would be of service, but I agree that braintwisting kinds are usually not good evening fare.