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
Static array and domain types #20250
Comments
As a practical matter, we can delay implementing the static types. Initially we can make it an error to (attempt to) obtain or use a static type. |
@dlongnecke-cray made an interesting suggestion: |
It sounds to me like the biggest difference from today that this proposal brings is that the compiler would be able to distinguish, with a given |
Indeed, the compiler would distinguish static-only types from runtime types for array and domain types. This allows the compiler to disallow the places where the runtime component is required yet is not available. Today the compiler does not track the availability of the runtime component. The codes that are sound and well-defined w.r.t. runtime types today should continue working as-is. |
OK. Then another way to market this proposal would be "Let's get a proper compilation error for the cases with runtime types that don't work today". Which makes sense to me as an approach (especially if #19292 does not seem attainable). |
Again as a practical matter, it will benefit chapel developers more if we can eliminate runtime types altogether, as in #19292. This is because they add noticeable complexity to the implementation. |
@vasslitvinov - I see that this is marked with Chapel 2.0 but it's not clear to me what program(s) would break / change behavior after this proposal? Could you clarify? Or, put another way, if we want to keep our options open, what would we have to mark unstable to allow us to do this after 2.0? |
@vasslitvinov - I see in your ranges chart that "remove runtime types" is considered done. Does that mean this issue can be closed? |
I consider this a sibling-slash-child of #19292. While we are not doing either for 2.0, let us keep both a consideration in the long term. For now, I removed the 2.0 label. |
This is a gentler alternative to #19292. This proposal allows us to address the runtime-type-related issues in semantics and implementation and to "legalize" skyline arrays, de-facto available since #8073.
Basic Principles
We propose to introduce static array and domain types as distinct from runtime types. The static types are available during compilation, with user-facing semantics.
Each runtime type has a corresponding static type. The static type is obtained from a runtime type by discarding the runtime component.
The type of an expression is a runtime type only in the cases where the runtime component is available. Otherwise it is a static type.
Generic types - other than array/domain types - are always instantiated with static types.
When the type of a variable is declared with a static array/domain type, it cannot be default-initialized.
Here "variable" includes fields, tuple components, array elements, and formals.
Details
Consider a variable declared with a static array/domain type. Once it is initialized,
aVariable.type
returns a runtime type. This runtime type is derived from the value held inaVariable
.An array/domain-typed field in a record can be default-initialized as long as there is a corresponding runtime type coming into the initializer. For example:
Skyline arrays are where this proposal shines. The element type of a skyline array is a STATIC array type. We cannot get to the domain of the element type from the type of the skyline array itself. Cf. the runtime type of a given element of a skyline array A is available as
A[i].type
.When an array stores an iterable expression with array elements, the enclosing array's element type is static. This is somewhat similar to skyline arrays.
A static array type could be written as
[domain(2)] real
.We could introduce a built-in method
EXPR.staticType
that produces the static type when EXPR is an array/domain value or type. In the other cases it is the same as EXPR.type.Related issues
Bugs:
#11549 handle record and class types with runtime types
#15929 Problem with runtime type and default initialization
#20050 internal compiler error / instantiating a type field with an array type
Semantics:
#8152 what should
.eltType
do for skyline arrays?#11220 Runtime type for an array of arrays
Skyline-related:
#11254 forall-over-forall results in empty array
#11039 for/forall expression with arrays as elements does not work
#11884 avoid extra iterator invocation upon reduce
#11882 avoid evaluating the argument of .type (see the discussion)
The text was updated successfully, but these errors were encountered: