RE: about GHC API: Looking up names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: about GHC API: Looking up names

GHC - devs mailing list

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: [hidden email] [mailto:[hidden email]] On Behalf Of Ranjit Jhala
Sent: 09 February 2018 04:41
To: Simon Peyton Jones <[hidden email]>
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`

would work, but apparently not?

Any clues? Thanks!

- Ranjit.

 

 

On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala <[hidden email]> wrote:

Will do! Best, Ranjit.

 

On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Ranjit Jhala
Sent: 31 January 2018 19:14
To: Simon Peyton Jones <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Ranjit Jhala
Sent: 26 January 2018 02:12
To: Simon Peyton Jones <[hidden email]>
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs