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

after and layout polymorphism #412

Open
zilinc opened this issue Jun 29, 2022 · 1 comment
Open

after and layout polymorphism #412

zilinc opened this issue Jun 29, 2022 · 1 comment

Comments

@zilinc
Copy link

zilinc commented Jun 29, 2022

In a nutshell, defaulting implicit offset to after is not compatible with layout polymorphism. One concrete example is:

type PairBool = { a : Bool, b : Bool }
layout L x = record {a : x, b : x}

id : all (x :~ Bool). PairBool layout (L x) -> PairBool layout (L x)
id x = x

foo : PairBool layout (L 1b) -> PairBool layout (L 1b)
foo x = id x

The foo function's type signature will be expanded to PairBool layout record { a : 1b, b : 1b at 1b } -> ... according to the implicit after semantics. At the call site of id inside foo, the surface TC will explicitly apply types and layout to id, rendering it id [] {{1b}}. When the Core TC sees it, it will infer the type to be PairBool layout record { a : 1b, b : 1b } -> ... by layout substitution, as the core doesn't have after. So the inferred type of id x is different from the type signature.

@zilinc
Copy link
Author

zilinc commented Jun 29, 2022

The easy solution is to reject after layouts if its offset depends on layout variables. The ultimate solution is to add after to Core.

zilinc pushed a commit that referenced this issue Jun 29, 2022
reject the use of `after` unless we can calculate the absolute offset
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant