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.


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 ~ 
or with, which some more detail, looks like

   (~ (TYPE LiftedRep) typ 
I would have thought that `Type.isEqPred` or `Type.isNomEqPred`
described here

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?



From: rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu> 
[mailto:rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu>] On Behalf Of Ranjit 
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


to get the


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?


- 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


From: rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu> 
[mailto:rjh...@eng.ucsd.edu<mailto:rjh...@eng.ucsd.edu>] On Behalf Of Ranjit 
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 

Does you know what it is?

Thanks in advance!

ghc-devs mailing list

Reply via email to