RE:: Can a TC plugin create new skolem vars when simplifying Givens?

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

RE:: Can a TC plugin create new skolem vars when simplifying Givens?

GHC - devs mailing list

Nick writes

Here's a small indicative example. In the "simplify Givens" step, the plugin receives

  [G] (p `Union` Singleton A) ~ (q `Union` Singleton B)

and I would ideally simplify that to

  [G] p ~ (x `Union` Singleton B)

  [G] q ~ (x `Union` Singleton A)

 

If we think of Union as a type-level function (which it is?), then the step you outline above is similar to what happens during “flattening” of the Givens.  We get this:

[G] fsk1 ~ p `Union` Singleton B    (CFunEqCan)

[G] fsk2 ~ q `Union` Singleton A    (CFunEqCan)

[G] fsk1 ~ fsk2                     (CTyEqCan)

 

  • The newly generated skolems are called “flatten-skolems” or fsks for short.
  • The new skolems are kept in the `inert_fsks` field of the `InertSet`. 
  • A new one is created by `TcSMonad.newFlattenSkolem`
  • All fsks are eliminated by TsSMonad.unflattenGivens

 

Returning to your point, you are exploiting a property of sets that allows you to say that if

                p U X  =   q U Y

Then suppose r = p Ç q

then   p = r U Y, q = r U X

 

And now we can eliminate all uses of p, q in favour of r.   But if you do this in a type system, we have a problem: where is ‘r’ bound?  E.g. if you have

f :: forall p q. (p `Union` A) ~ (q `Union` B) => blah

Then p, q are bound by the forall, but r is not.  To put it another way, what well-typed Core program would you like to generate?

 

You could do this:

[G] fsk1 ~ p `Union` Singleton B    (CFunEqCan)

[G] fsk2 ~ q `Union` Singleton A    (CFunEqCan)

[G] fsk3 ~ p `Intersect` q          (CFunEqCan)

[G] fsk4 ~ fsk3 `Union` Singleton B  (CFunEqCan)

[G] fsk5 ~ fsk3 `Union` Singleton A  (CFunEqCan)

[G] fsk1 ~ fsk2                     (CTyEqCan)

[G] p ~ fks4                         (CTyEqCan)

[G] q ~ fsk5                         (CTyEqCan)

 

The ‘r’ is just fsk3.  It’ll be eliminated by unflattenGivens, so there is no problem with scoping.

 

I have no idea whether that’ll help you prove the things you want to prove!

 

Simon

 

 

 

From: ghc-devs <[hidden email]> On Behalf Of Nicolas Frisby
Sent: 24 June 2018 19:01
To: [hidden email]
Subject: Can a TC plugin create new skolem vars when simplifying Givens?

 

I'm still spending the occasional weekend working on a type checker plugin for row types (actually "set" types at first, but I haven't thought of a less ambiguous term for that).

 

One point of complexity in the plugin has to do with creating fresh variables when simplifying Givens. Some constraints are traditionally simplified by introducing a fresh variable. For Wanted constraints, that's easy (newFlexiTyVar). For Givens, though, I haven't figured out how to do it.

 

This email is just to ask these two questions:

 

    1) Is there a function to add a new skolem variable when simplifying Givens?

 

    2) Assuming not, is there a strong reason for there to never be such a function?

 

Here's a small indicative example. In the "simplify Givens" step, the plugin receives

 

  [G] (p `Union` Singleton A) ~ (q `Union` Singleton B)

 

and I would ideally simplify that to

 

  [G] p ~ (x `Union` Singleton B)

  [G] q ~ (x `Union` Singleton A)

 

for some fresh skolem variable x. But I don't see how to properly create a fresh skolem variable in the Givens. If these were Wanteds, I would just use newFlexiTyVar.

 

I think this is analogous to a hypothetical type checker plugin that eta expands tuples. If we were to simplify

 

  [G] ... (x :: (k1,k2)) ...

 

to

 

  [G] ... '(x1 :: k1,x2 :: k2) ...

 

we'd have to generate x1 and x2 somehow. The only method I'm aware of for that is to use Fst x and Snd x instead (ie type families). That might be acceptable for the tuple expansion example, but I'm very reticent to use something like that for the set types plugin.

 

I have a plan to get by without creating these variables when simplifying Givens, but it's not simple. I'd be delighted if it were possible to create them. Hence my two questions listed above.

 

Thank you for your time. -Nick


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs