-
Notifications
You must be signed in to change notification settings - Fork 323
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
Allow (multi_value : Table) : Column
to succeed
#11482
Comments
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-11): Progress: .
Next Day: Being at javadays.cz conference |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-12): Progress: .
Next Day: Next day I will be working on the #11482 task. Delivering Enso talk at javadays.cz conference |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-13): Progress: .
Next Day: Next day I will be working on the #11482 task. Back to work |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-14): Progress: .
Next Day: Finish type check refactoring, then up to
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-15): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-18): Progress: .
|
While working on #11482 and enhancing the tests suite with more tests based on `type Complex` a [getRootNode() did not terminate in 100000 iterations](#11525 (comment)) problem was discovered. Detailed investigation revealed that the existing `ReadArgumentCheckNode` infrastructure was able to create a **cycle** of parent pointers in the Truffle AST. The problem was in intricate manipulation of the AST while rewriting internals in `ReadArgumentCheckNode`. This PR avoids such manipulation by _refactoring the type checking code_. `ReadArgumentNode` knows nothing about types anymore. When a type check is needed, `IrToTruffle` adds additional `TypeCheckValueNode.wrap` around the `ReadArgumentNode` - that breaks the **vicious circle**. All the _type checks_ nodes are moved to its own package. All but one of the classes are made package private. The external API for doing _type checking_ is concentrated into `TypeCheckValueNode`.
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-19): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-20): Progress: .
|
While working on #11482 and enhancing the tests suite with more tests based on `type Complex` a [getRootNode() did not terminate in 100000 iterations](#11525 (comment)) problem was discovered. Detailed investigation revealed that the existing `ReadArgumentCheckNode` infrastructure was able to create a **cycle** of parent pointers in the Truffle AST. The problem was in intricate manipulation of the AST while rewriting internals in `ReadArgumentCheckNode`. This PR avoids such manipulation by _refactoring the type checking code_. `ReadArgumentNode` knows nothing about types anymore. When a type check is needed, `IrToTruffle` adds additional `TypeCheckValueNode.wrap` around the `ReadArgumentNode` - that breaks the **vicious circle**. All the _type checks_ nodes are moved to its own package. All but one of the classes are made package private. The external API for doing _type checking_ is concentrated into `TypeCheckValueNode`.
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-21): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-22): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-25): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-27): Progress: .
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-11-28): Progress: .
|
Jaroslav Tulach reports a new STANDUP for today (2024-11-29): Progress: .
|
The decision to support
and especially handle the Treat single column Table as a Column request, we are going to use multi values representing multiple types at once.
Multi value & type check
When the library code needs, it can create a multi value representing both
Table
andColumn
at once. However, when there is a return value check like-> Table
- such a value would be converted to just a table. That shall no longer be the case - we need multi values to pass thru. A solution for this has already been provided once:However such a solution worked poorly with potential static analysis.
Solution
The goal of this PR is to split the intersection type of an
EnsoMultiValue
into two parts:The text was updated successfully, but these errors were encountered: