Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Internal] Improve Constraint Solving #6

Open
tnowacki opened this issue Sep 13, 2018 · 1 comment
Open

[Internal] Improve Constraint Solving #6

tnowacki opened this issue Sep 13, 2018 · 1 comment

Comments

@tnowacki
Copy link

We should collapse most constraints into into a single type when possible.

For example

fun ex<U, T: Show & Eq & U> 

We get an upper bounds array of

T => [%Show, %Eq, U]

We should instead collapse these into a single point
So

T => [-{Show, Eq}, U]

We can likely accomplish this by contra-promote joining the constraints
There are likely some issues though around tuples.
Such as

fun ex<T: (L, R) & (R, L)>

And even worse with

fun ex<U: R, T: (L, U) & (U, L)>

Since you likely want

T => [(L, U), (U, L), (L & R, L & R)]

But if we can accomplish this simplification it will

  • Likely allow some simplifications for code when adding whenparams/conditional constraints
  • Open up statics on tparams/generics
@tnowacki tnowacki changed the title Improve Constraint Solving [Core] Improve Constraint Solving Sep 14, 2018
@tnowacki tnowacki changed the title [Core] Improve Constraint Solving [Internal] Improve Constraint Solving Sep 14, 2018
@pikatchu
Copy link
Collaborator

To open up statics on tparams/generics, we would have to have the guarantee that the simplification always works right? We would need a normal form I think.

What would that normal form look like, imagining that we had one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants