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
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.Inthttps://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.Inthttps://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/T...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 mailto:jhala@cs.ucsd.edu> wrote:
Will do! Best, Ranjit.
On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones 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.edumailto:rjhala@eng.ucsd.edu [mailto:rjhala@eng.ucsd.edumailto:rjhala@eng.ucsd.edu] On Behalf Of Ranjit Jhala
Sent: 31 January 2018 19:14
To: Simon Peyton Jones 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 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.edumailto:rjhala@eng.ucsd.edu [mailto:rjhala@eng.ucsd.edumailto:rjhala@eng.ucsd.edu] On Behalf Of Ranjit Jhala
Sent: 26 January 2018 02:12
To: Simon Peyton Jones 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!
