Ranjit Have you read Note [The equality types story] in compiler/prelude/TysPrim? As you’ll see (~) is actually a class; the equality predicate is (~#). There doesn’t seems to be a named-function predicate that checks for it explicitly, but if you grep for eqTyCon you’ll see lots of tests for it. I’m sure these tests could be tideied up into a smaller collection of predicates. Simon From: rjhala@eng.ucsd.edu [mailto:rjhala@eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 09 February 2018 04:41 To: Simon Peyton Jones <simonpj@microsoft.com> Subject: Re: about GHC API: Looking up names Dear Simon, still working on the above, but hit an odd problem on the way. How can I "test for" (i.e. write a function of type `Type -> Bool`) that returns `True` for values (i.e. `Type`s) that print out as: typ ~ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.Int&data=04%7C01%7Csimonpj%40microsoft.com%7C29c2e5ecd0f04842953508d56f774eca%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636537480568476914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=KKRza3vDtm0mAlSP%2F4XzltIh5XqGlc9CY3tAXrUzF10%3D&reserved=0> or with, which some more detail, looks like (~ (TYPE LiftedRep) typ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.Int&data=04%7C01%7Csimonpj%40microsoft.com%7C29c2e5ecd0f04842953508d56f774eca%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636537480568476914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=KKRza3vDtm0mAlSP%2F4XzltIh5XqGlc9CY3tAXrUzF10%3D&reserved=0>) I would have thought that `Type.isEqPred` or `Type.isNomEqPred` described here https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/src/Type.html#isEqPred<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2F8.2.1%2Fdocs%2Fhtml%2Flibraries%2Fghc-8.2.1%2Fsrc%2FType.html%23isEqPred&data=04%7C01%7Csimonpj%40microsoft.com%7C29c2e5ecd0f04842953508d56f774eca%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636537480568476914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=sM%2F3Xje4uR3MLwy4wHY28RWqiyq9JauXXO1lrHAgiYs%3D&reserved=0> would work, but apparently not? Any clues? Thanks! - Ranjit. On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala <jhala@cs.ucsd.edu<mailto:jhala@cs.ucsd.edu>> wrote: Will do! Best, Ranjit. On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> wrote: I’m glad you are un-glued, but it smells wrong to me and your solution seems like a workaround for a bug, not the Right Path. Could you make a ticket with a repro case? Thanks! Simon From: rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 31 January 2018 19:14 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: about GHC API: Looking up names Dear Simon, No worries, I was able to figure it out, or at least work around it.

It’s very mysterious that declaring it in an instance decl would make any difference.

It looks like that is exactly what is happening, but perhaps by design? (I saw there was something called an `ImplicitTyThing` that are not in the top-level scope, so I figured that perhaps these instance declarations were "implicit" and hence not available?) Nevertheless, I was able to work around the issue by using `tcGetFamInstEnvs` to get the `FamInstEnv` and from that, making my own lookup environment (comprising the TyCon and DataCon for the family instances.) This works for my purposes, but if the above is a possible bug, I can try to make a small test case? Thanks! - Ranjit. On Wed, Jan 31, 2018 at 1:47 AM, Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> wrote: Hi Ranjit That does sound odd. You should ask on ghc-devs too… though you may already have done that. hscTcRnLookupName doesn’t do anything fancy: it just looks up the Name in the type environment. It’s very mysterious that declaring it in an instance decl would make any difference. I suppose you could somehow have gotten hold of the wrong Name. If I was debugging it, I’d start spitting out traces showing the type environment it is looking up in, to see what is there and what is not. If you make a small standalone test case (e.g. a tiny client of the GHC API that demonstrates the problem) that could enable others to reproduce and help you. Or, I guess, we could do a Skype chat with you trying things locally. I wish I could help more Simon From: rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 26 January 2018 02:12 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Subject: Q: about GHC API: Looking up names Dear Simon, I have a question about the GHC API I wonder you can help with? Suppose `Library.hs` is has the constructors defined in the simple top-level style: ``` data EntityField typ where BlobXVal :: EntityField Int BlobYVal :: EntityField Int ``` Then when analyzing `Client.hs` (that imports `Library`), the lookup function `hscTcRcLookupName` WORKS just fine to give me the `TyThing` corresponding to the name “BlobXVal”. However, if instead, Library.hs defines the constructors within an instance: ``` instance PersistEntity Blob where data EntityField Blob typ where BlobXVal :: EntityField Blob Int BlobYVal :: EntityField Blob Int ``` then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS to resolve the name. Clearly there is some difference in how `hscTcRcLookupName` works in these two cases. Does you know what it is? Thanks in advance!