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

Type Erasure, Dynamic, Coercions #18

Open
croyzor opened this issue Jul 25, 2024 · 0 comments
Open

Type Erasure, Dynamic, Coercions #18

croyzor opened this issue Jul 25, 2024 · 0 comments

Comments

@croyzor
Copy link
Collaborator

croyzor commented Jul 25, 2024

Originally raised by @acl-cqc:

  • Currently (on main) kind arguments and any value whose type is an earlier (kind) argument are compiled to a Hugr parameter of type unit (i.e. Sum([[]]))
  • Instead, arguments whose type is a kind argument should be compiled to have some extension-defined type Dynamic
  • The kind arguments themselves might be ok as unit, at least for now - we may need to represent those too eventually (e.g. for dependent tuples), i.e. if any backend needs runtime type information (?)
  • We'll also need to fix the type errors in Hugr validation - any time a value of known type is converted to a Dynamic, or vice versa, and also any time a graph/higher-order-function-value (say Int->Int passed into a Dynamic->Dynamic), we'll need to add a magic coercion op
acl-cqc added a commit that referenced this issue Oct 21, 2024
* Driveby cleanups of some misnamed `examples/`
* Add monomorphic test so it compiles+validaties rather than having any type erasure issues (#18)
croyzor pushed a commit that referenced this issue Oct 24, 2024
* Driveby cleanups of some misnamed `examples/`
* Add monomorphic test so it compiles+validaties rather than having any type erasure issues (#18)
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

1 participant