[code-reflection] RFR: Extensible types in the code model

[Paul Sandoz]

On Mon, 12 Feb 2024 20:41:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Prior to this PR types in the code model were modeled as general "type descriptors" and therefore did not differentiate between kinds of type.  This lack of differentiation is confusing and limiting. The code model defines type descriptions for modeling variables, tuples, and Java types, but they all look the same at runtime and we cannot easily differentiate between them - former two confusingly suggests they are like the latter.
> 
> We enhance the modeling of types and make types extensible in the code model.
> 
> A value has an instance of `TypeElement`, an unsealed interface from which one can extend to model any kind of type. The interface `JavaType` extends from  `TypeElement` and symbolically models Java types. The types `VarType` and `TupleType` are general code model types that model variables and tuples, they are not Java types but they may contain Java types, or any other type elements (including themselves).
> 
> The Triton PoC example has also been updated. The types that were defined to model tensors and pointers can be embedded directly into code models.
> 
> The relationship between Java descriptors (method, method type, field, and record) are now a clearer.
> 
> In subsequent PRs we will iterate to further improve this area:
> 1. Replace the use of `MethodTypeDesc` in the core API with `FunctionType`, that models a function type (or arrow type).  
> 2. Improve boundary between `TypeElement` and the parser. Currently we are reusing the original `TypeDesc` class for this as a temporary solution.
> 3. Devise a richer modeling of Java types. Currently `JavaType` is mostly a clone of `TypeDesc`. But we can do much better perhaps providing similar fidelity as the `javax.lang.model.type.TypeMirror` API.

I will explore changing `TypeDefinition` to be a record:

record TypeDefinition(String identifier, List<TypeDefinition>) {};
``` 
`TypeElement`s are constructed from that using the factory, and there can be a method on `TypeElement`:

  Optional<TypeDefinition> toDefinition();

That more cleanly separates out the parsing and serializing contracts, where parsing and serializing integration is optional. It also likely requires adjusting the grammar of the serialized definitions in the current textual form.

We now have the opportunity to think more clearly about modeling Java types more comprehensively, decide about the descriptors (such as MethodDesc, FieldDesc etc, are they types or a means to aid the reflection operations?), and their resolution (and perhaps even Java type comparison beyond quality). In part it depends on how we decide to model Java types.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/18#issuecomment-1941969054