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

or with, which some more detail, looks like

   (~ (TYPE LiftedRep) typ GHC.Types.Int)

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

would work, but apparently not?

Any clues? Thanks!

- Ranjit.

On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala <jhala@cs.ucsd.edu> wrote:

Will do! Best, Ranjit.

On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <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] On Behalf Of Ranjit Jhala
Sent: 31 January 2018 19:14
To: Simon Peyton Jones <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> 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] On Behalf Of Ranjit Jhala
Sent: 26 January 2018 02:12
To: Simon Peyton Jones <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!