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

Reply via email to