about GHC API: Looking up names

Fri Feb 9 09:34:12 UTC 2018

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 at eng.ucsd.edu [mailto:rjhala at eng.ucsd.edu] On Behalf Of Ranjit Jhala
Sent: 09 February 2018 04:41
To: Simon Peyton Jones <simonpj at 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 <jhala at cs.ucsd.edu<mailto:jhala at cs.ucsd.edu>> wrote:
Will do! Best, Ranjit.

On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at 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 at eng.ucsd.edu<mailto:rjhala at eng.ucsd.edu> [mailto:rjhala at eng.ucsd.edu<mailto:rjhala at eng.ucsd.edu>] On Behalf Of Ranjit Jhala
Sent: 31 January 2018 19:14
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at 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 at microsoft.com<mailto:simonpj at 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 at eng.ucsd.edu<mailto:rjhala at eng.ucsd.edu> [mailto:rjhala at eng.ucsd.edu<mailto:rjhala at eng.ucsd.edu>] On Behalf Of Ranjit Jhala
Sent: 26 January 2018 02:12
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at 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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180209/a8f244c4/attachment-0001.html>