-
Notifications
You must be signed in to change notification settings - Fork 150
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
Add notes for 8/23 GC meeting #1097
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for running this meeting and taking notes, @dtig!
|
||
BT: Ran into this problem for func.bind, which has a synthesized type, we run into the same issue with any type of inference that it creates types that you haven’t written down. It’s because we have this subtyping relationship that we have to declare, if you haven’t written one of the subtypes in the chain, it’s essentially a synthesized type, and how is that type canonicalized? We don’t have to mandate type canonicalization | ||
|
||
AR: LUBs only work when you have proper lattice in the type system, or at least a semi lattice. For br_table you need GLBs (?) so you would need a full lattice, that’s a severe constraint. There are cases where you can’t synthesize a proper type, there is no principle type that you could synthesize, it’s not clear how you would solve this problem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rossberg, why would br_table need GLBs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlively, this was a problem we ran into when we introduced reference types and that we could only fix by adding bottom, see my presentation from June 2019: https://github.com/WebAssembly/meetings/blob/main/main/2019/presentations/2019-06-rossberg-reference-types.pdf
FWIW, people keep being surprised by this one, see e.g. this very recent comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that makes sense.
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
Co-authored-by: Thomas Lively <[email protected]>
|
||
BT: Ran into this problem for func.bind, which has a synthesized type, we run into the same issue with any type of inference that it creates types that you haven’t written down. It’s because we have this subtyping relationship that we have to declare, if you haven’t written one of the subtypes in the chain, it’s essentially a synthesized type, and how is that type canonicalized? We don’t have to mandate type canonicalization | ||
|
||
AR: LUBs only work when you have proper lattice in the type system, or at least a semi lattice. For br_table you need GLBs (?) so you would need a full lattice, that’s a severe constraint. There are cases where you can’t synthesize a proper type, there is no principle type that you could synthesize, it’s not clear how you would solve this problem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlively, this was a problem we ran into when we introduced reference types and that we could only fix by adding bottom, see my presentation from June 2019: https://github.com/WebAssembly/meetings/blob/main/main/2019/presentations/2019-06-rossberg-reference-types.pdf
FWIW, people keep being surprised by this one, see e.g. this very recent comment.
Co-authored-by: Andreas Rossberg <[email protected]>
Co-authored-by: Andreas Rossberg <[email protected]>
No description provided.