[code-reflection] RFR: JavaRef extends TypeElement

[Paul Sandoz]

On Wed, 30 Apr 2025 08:39:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Re s-expressions, it struck me that an alternate, more verbose representation, would be one where we have no sigils, but we use function application, and the function name determines the type being constructed. E.g. instead of:

That seems more principled. We could consider that after we have tackled the human readability of Java types. What might also help is what dialect the externalized type is associated with (and more generally for ops), which allows for a better association of factories.

For non-Java types, the approach works quite nicely so far in many cases e.g., in the Triton or ONNX examples, where we don't really require sigils. Dialect identification would be useful because we can mix types from different dialects e.g., Triton reuses Java primitive types such as for `tensor<x32, x64, float>`, so we would use the externalized form of the Java type here rather than the human readable form given it is nested.

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

PR Comment: https://git.openjdk.org/babylon/pull/416#issuecomment-2842936925