-
Notifications
You must be signed in to change notification settings - Fork 696
Native GC Subtyping Support #289
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
Comments
Two options for record subtyping are width and depth subtyping (basically, longer structs are subtypes of shorter structs, and structs with corresponding immutable fields that are subtypes are subtypes). Both make sense and are being considered. |
To add to that, I think it is a goal to have the low level builtins be flexible enough to define virtual dispatch in terms of structs containing function pointer fields. |
I agree that we want to give the flexibility for building vtables and more complex object structures to implementations of languages running "on top of" wasm. A key issue here is how much static typechecking we can do for things like structs that represent virtual dispatch tables. There is a line of research on typed intermediate languages that could be fruitful here, e.g. the work by Neal Glew and other work by Juan Chen. |
This should be hanedled by the proposal for GC. |
The native GC is supposed to be low level and is defined mostly in terms of structs. How would subtyping be implemented on top of this? Is it similar to C where a pointer can be converted if the first element of a struct is another? And will the support for virtual dispatch be flexible enough to allow for interfaces?
The text was updated successfully, but these errors were encountered: