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

[Hannes Greule]

On Thu, 28 Mar 2024 16:15:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> If we lean into a test template approach with transformations then dealing with a template that is an instance method does not seem too difficult, just drop the first block parameter when transforming (any uses of that parameter means a test infrastructure bug) or pass the test instance argument.
> 
> The parameterized approach would i think be more familiar. If you like and have the time perhaps experiment with both appraoches? Perhaps there are valid uses for both kinds of approaches? Otherwise pick the one you think is better. I expect we might iterate on this area in subsequent PRs.

I'll try out both to see how it turns out, but it might take a few days.

> I wonder if, understandably, when initially encountering operation it is thought about in the more conventional sense e.g., add two numbers? 

As `FuncOp` is one of the two main entry points to the API (at least from my view, besides going through `Quoted`), I think that's not too much of a concern overall.

> But, it does not have to be. We can define an operation that _declares_ a function, and its result type is certainly not the type of what the function returns when invoked, and it may not have a meaningful result (hence `void`, which i admit adds to the confusion, and perhaps `FunctionType` is more honest which would be equivalent to that returned by `invokableType`).
> 
> We do have a common interface that abstracts invokable operations, `Op.Invokable`, and that declares method `invokableType`.

When comparing to `LambdaOp`, the meaning of `resultType` is clearer as we just have an expression there. I think the main source of my confusion was that `resultType` showed up directly in the IDE while getting to the return type is more difficult, combined with the fact that methods in Java are neither expressions nor statements, so it's kind of "what else would it be if not the return type?" But I also see how it makes sense to have it modeled this way, it still has most things in common with other Ops and a more fine-grained type hierarchy might be even more confusing or annoying to work with.

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`...)

That's just a few thoughts, maybe it's something we shouldn't be too concerned with for now.

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

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