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.

Sign up for GitHub

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

Jump to bottom

No polymorphic closures #904

Closed
Tracked by #416
acl-cqc opened this issue Apr 2, 2024 · 2 comments · Fixed by #906
Closed
Tracked by #416

No polymorphic closures #904

acl-cqc opened this issue Apr 2, 2024 · 2 comments · Fixed by #906
Assignees
@acl-cqc
Milestone
v0.3.0

Comments

@acl-cqc
Copy link
Contributor

acl-cqc commented Apr 2, 2024 •
edited
Loading

  • Only FuncDefn (and FuncDecl) may declare binders
  • Type hierarchy includes monomorphic function types only, not polymorphic ones.
  • Two distinct EdgeKinds: one for values/closures (from Consts to their uses, including CallIndirect), i.e. no polymorphism; and one for functions (carries a polymorphic function type from a FuncDecl/Defn to a Call, only).
  • Thus, no TypeApply, but Call does type application, as per fix: polymorphic calls #901
  • Should simplify substitution logic as we no longer need to substitute polymorphic types in place of type variables, and don't need to substitute under binders (binders are only at the outermost level - function or opdef)
@acl-cqc acl-cqc self-assigned this Apr 2, 2024
@acl-cqc acl-cqc mentioned this issue Apr 2, 2024
Closed
10 tasks
@aborgna-q aborgna-q added this to the v0.3.0 milestone Apr 2, 2024
This was referenced Apr 2, 2024
Merged
Open
@croyzor
Copy link
Contributor

croyzor commented Apr 8, 2024

The spec says that a FuncDefn is the child of a dataflow container, meaning that they can be nested. Should this be updated to say that FuncDefn can only be the child of a Module?

@acl-cqc
Copy link
Contributor Author

acl-cqc commented Apr 8, 2024

The spec says that a FuncDefn is the child of a dataflow container, meaning that they can be nested. Should this be updated to say that FuncDefn can only be the child of a Module?

No - but nesting is purely for namespacing/scoping (a "local" funcdefn can only have nonlocal edges to things within the same parent). A local funcdefn already cannot refer to any enclosing TypeParams, this is checked in validation.

@croyzor croyzor mentioned this issue Apr 8, 2024
Closed
github-merge-queue bot pushed a commit that referenced this issue Apr 9, 2024
@acl-cqc
feat: No polymorphic closures (#906)
b05dd6b 
* Type::Function now stores only a FunctionType, not a PolyFuncType
* PolyFuncType remains, for OpDef's and FuncDefn/Decl's
* EdgeKind::Static now replaced by EdgeKind::Const (a type)
EdgeKind::Static (a PolyFuncType)
* Remove LeafOp::TypeApply, repurpose validation code onto Call
* Thus, progressively remove all `impl Substitution`s except for `struct
SubstValues`, which can become Substitution
* Update spec, introducing "Static" and "Dataflow" edge kinds as broader
classes of the other edge kinds, and polymorphic "type schemes" vs
monomorphic "Function types".
* Update serialization schema and add roundtrip test of a Noop operating
on a value of function type

fixes #904

This should enable resolving #788 and related capture/closure issues if
we forbid edges into a FuncDefn from outside (@doug-q)

BREAKING CHANGE: EdgeKind::{Static -> Const}, add new
EdgeKind::Function, Type contains only monomorphic functions, remove
TypeApply.
This was referenced Apr 10, 2024
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@acl-cqc acl-cqc

Labels
None yet
Projects
None yet
Milestone
v0.3.0
Development

Successfully merging a pull request may close this issue.

feat: No polymorphic closures CQCL/hugr
3 participants
@croyzor @acl-cqc @aborgna-q