-
Notifications
You must be signed in to change notification settings - Fork 0
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
Connect the subtyping layers in a different way (for supremum) #136
Comments
Even though this seems to be hacky, our existing examples never actually failed because of this problem. So this is not high priority. |
We now have an example in which our adhoc solution failes. DescriptionCurrently our procedure is very ad-hoc. During supremum solving subtyping constraints are created, which are then reintegrated into a supremum constraint here. The problem is that this is not done always (as in this location of execution we do not have the information about where a given set of subtyping constraints came from, and we have to restrict ourselves to cases where we know that we do not break other constraints - i.e. when the RHS does not occur in other constraints). The Problematic exampleAs seen in the following example though, there are situations we do not reconstruct even though we should. Example: julia> typecheck_hs_from_string_detailed("module F
function test()
a = 3
b = 5
function f(a,b)
a1 = 7
function g(ff)
(a,b) -> ff(a,b)
end
function h(a,b)
b1 = 3
a + b1
end
g(h)(a1,b)
end
y = b + 12
b2 = 9
x = a
a2 = 12
f(x,y)
end
end
") Log:
The constraints IdeaWe want a proper connection of the subtyping levels. |
This seems to be too difficult to do properly. Our current system isn't that bad as well. |
Currently, we have a function
convertSubtypingToSupremum
which builds a supremum from multiple subtyping constraints.This is needed because when resolving suprema using the subtyping graph, we forget that stuff was a supremum, and construct subtyping constraints from that. Which later are turned into suprema by that function.
This is quite unsatisfactory, since information is lost. It would be best, if we would do this directly.
For example, discharging bot/top constraints has now to be done in a later phase (59b66f0), to make sure that the supremum restoration runs before it. Even in that later phase, the question whether all restorations happen as supposed is not quite clear.
The text was updated successfully, but these errors were encountered: