type ForallXPat (c :: * -> Constraint) (x :: *) =…

 

               What is this?  Why do we need it? What goes wrong if we remove it altogether?

 

 

Overall I’ve lost track of these enormous constraint tuples that seem to be associated with Data instances. Can you give a small artificial (ie not full GHC) example of why they are necessary?   Perhaps it’s this

 

data T p = T1 (XT1 p) Int
                | T1 (XT2 p) (IdP p)

 

I suppose that a Data instance would need to have

               instance (Data (XT1 p), Data (XT2p), Data (IdP p)) => Data IT p) where…

Is that right?  In which case why do you have all this PostRn stuff in the DataId type?  (And why is it called DataId?)

 

It’d be great to explore these issues with small, concrete examples, rather than the full glory of GHC, both for our own benefit and the benefit of those who will review the patch and (in future) understand the code.

 

Sorry to be slow

 

Simon

 

 

From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com]
Sent: 23 October 2017 22:36
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: ghc-devs@haskell.org
Subject: Re: forall in constraint

 

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
      (XIB x thing)
      thing

  | NewImplicitBndrs
      (XNewImplicitBndrs x thing)

type family XIB               x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
       ( c (XIB               x thing)
       , c (XNewImplicitBndrs x thing)
       )

This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)

where `thing` is resolved to a specific type.

 

Because it is all in the same file, there is no problem making a

constraint on anything using LSigType, that mentions LHsType.

 

 

 

But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

 

In order to derive a Data instance for anything using `LSigType x`, we

need to be able to specify that a Data instance exists for `LHsType x`.

 

So we can either do that directly in HsBinds, or try to add it to the existing

DataId constraint in HsExtension.

 

The first approach leads to a spread of the constraint throughout the AST,

which gets very messy.

 

The second approach requires being able to specify a

`forall thing. Data thing` constraint in HsExtension.

 

 

I tried an intermediate approach, introducing a constraint in HsDecls[3] to capture this,

but it eventually runs into needing it in the HsExpr.hs-boot file, which means I need

LHsType in that file.

 

Perhaps the simplest way forward is to get rid of the `thing` parameter completely,
and introduce the three or so ImplicitBinders variants that are used.

 

I hope this does not just confuse things even more.

 

Alan

[3] https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439

 

 

 

On 23 October 2017 at 23:04, Simon Peyton Jones <simonpj@microsoft.com> wrote:

I’m lost. Could you give me a bit more context?

 

I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher kinded parameters.   Smells all wrong to me.

 

Simon