You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement https://en.wikipedia.org/wiki/Hindley–Milner_type_system in Graphene. Or that might be unnecessarily complex and powerful for our needs, where we just likely need bidirectional type inference, something akin to Rust's own ability to detect what a variable's declared type is based on usages. Essentially this means we'd have up-and-down type inference, like what's common in languages such as TS or Rust. This can help let us know which typed implementation of a node is the appropriate one to reference when a node input is disconnected (but it's not part of the rendered graph) and that input has to be set to some type's default value.
Type inference at declaration site when usage site is further up or down in the node flow (needed to allow the Number value node to have a built-in Into node)
changed the title [-]Make the Graphene type system more powerful[/-][+]Make the Graphene type system more powerful with HM type inference[/+]on May 29, 2024
changed the title [-]Make the Graphene type system more powerful with HM type inference[/-][+]Make the Graphene type system more powerful with bidirectional (or HM?) type inference[/+]on Mar 29, 2025
changed the title [-]Make the Graphene type system more powerful with bidirectional (or HM?) type inference[/-][+]Bidirectional type inference[/+]on Feb 10, 2026
Activity
[-]Make the Graphene type system more powerful[/-][+]Make the Graphene type system more powerful with HM type inference[/+][-]Make the Graphene type system more powerful with HM type inference[/-][+]Make the Graphene type system more powerful with bidirectional (or HM?) type inference[/+][-]Make the Graphene type system more powerful with bidirectional (or HM?) type inference[/-][+]Bidirectional type inference[/+]