[code-reflection] RFR: More systematic binary op tests

[Paul Sandoz]

On Thu, 28 Mar 2024 18:20:06 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> ... the fact that methods in Java are neither expressions nor statements

Right.
 
> I wonder if there are more examples of Ops that have a similar special position. I assume something like local classes/interfaces won't be modeled at all, and e.g. `assert` also returns void, where it makes sense I guess. (Or maybe it could be reasonable to have a separate Unit type? That might be more obvious when used wrongly, e.g. a `void` method currently returns `void` for `resultType`...)
>

Yeah, i think a code model unit type is clearer (rather than reusing `JavaType.VOID`, which is a likely source of confusion).

There's a "module" operation which has one body with one block whose operations should all be function declaration operations. This is similar to what MLIR does. That concept is used in the Triton example (see [here](https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/triton/src/test/java/oracle/code/triton/TestSoftMax.java#L39)). But, we have yet to use it for modeling Java code.

We don't intend to model class declarations -- i would very much like to avoid that. We are still working out exactly what to do when reflecting on code that has class declarations. It may be we surface up all the associated reflected methods as function declaration operations in a module operation.

Another place where module operations could appear is if someone wrote a transformation to translate lambdas similarly to what java compiler does when generating bytecode (the lambda is desugared into an invokedynamic a referenced method).

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

PR Comment: https://git.openjdk.org/babylon/pull/40#issuecomment-2025912486