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: rjh...@eng.ucsd.edu [mailto:rjh...@eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 09 February 2018 04:41 To: Simon Peyton Jones <simo...@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 <jh...@cs.ucsd.edu<mailto:jh...@cs.ucsd.edu>> wrote: Will do! Best, Ranjit. On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@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: rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu> [mailto:rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 31 January 2018 19:14 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@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 <simo...@microsoft.com<mailto:simo...@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: rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu> [mailto:rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 26 January 2018 02:12 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@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!
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
