Call for Dicussion: JEP: Java Expression Trees API

[Konstantin Triger]

Hi Paul,

On Mon, May 6, 2024 at 8:50 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Konstantin,
>
> > On May 4, 2024, at 4:06 AM, Konstantin Triger <kostat at gmail.com> wrote:
> >
> > Hi Paul,
> >
> > > I don’t think we should embed specific profiles of code into the
> platform.
> > This makes sense depending on what you mean by "embed". Today there is
> no way to specify anything. How will a library be able to know what profile
> @CodeReflection annotated method or Quoted lambda should conform to?
> >
>
> A library consuming code models specifies constraints on the Java
> programming model and the developer passing reflected code to that library
> is aware of those constraints. It may be possible in some cases for
> composition (code models in, code models out), for example a machine
> learning library could potentially leverage an auto-diff library. It’s
> still early days so it will be interesting to see how this plays out.
>
>
Potentially we misunderstood each other. I'm referring to the
design/compile time ability to report errors. Previously you mentioned that
you need to work out how a Java library can participate in analyzing models
at compile time. I think this is a must have feature and an expectation
from a statically compiled language.


>
> > --
> > Code Model analysis thoughts.
> > The current design defines a very lean set of Core ops and allows
> extensions (Extended ops), which basically go after language (e.g. Java)
> features. My understanding is that other eco languages should define their
> respective Extended ops.
>
> “Core” and “Extended” are poorly named, eventually we will find better
> names. The core and extended operations are designed to support the
> modeling of Java programs. Other "eco languages" do not need to depend on
> core ops. I think it depends on the use case and the target environment.
> They can also define their own distinct set of operations (e.g., see the
> Triton example), so they would depend on the meta-code model.
>

I don't really like this approach. This means "no guarantee for anything"
for the analyzing library. But at the end there is JBC, so if Core ops
would provide wrappers for the JBC instructions (and they do based on my
observation), it should be always possible to lower to that level. I'd
recommend that any non-Core op to be lowerable to the Core ops,
(potentially in more than one hop).
With this "guarantee" the analyzing library can be made generic.


>
> You make an interesting point about lowering and I have been wondering
> about that myself. But, I am wary of moving outside the domain of Java. We
> (Babylon team) need to keep very focused, otherwise the problem space
> becomes very large, and it’s already large! The meta-code model provides
> generic modeling of control flow (connected basic blocks), so for Java’s
> modeling purposes I did not see the need to add more abstract operations,
> such as a more general (lowerable) loop operation. I was thinking other’s
> can define their own operations for such purposes, or reinterpret the Java
> operations.
> (Note that in the Triton example we translate the for loop operation to a
> SSA-based counted loop. In an earlier design I tried to model Java
> high-level language constructs in SSA form. This quickly became complex, so
> backed off.)
>
> However, even if we keep a Java focus perhaps there are more intermediate
> (perhaps optional steps) in this regard to make analysis of Java programs
> easier, which just so happens to be more generally useful, just like the
> meta-code model is I think more generally useful. Lowering to generic
> (further lower able) operations would make a great example and test case.
>

I totally understand your time and resource constraints. Probably it is
impossible to provide a "perfect" intermediate op layer from the first
shot. But you already assumed that others could reinterpret Java ops. So
why not take some Java ops (slightly simplified/generalized) and put them
into generic "ExtendedCore"? I think that messaging here is the important
part. I.e. what is the API the analysis libraries should work with?


>
>
> > For the library developer this poses a dilemma: should I work with
> Extended or Core ops? Extended might be much easier, but can be a very
> diverse + constantly moving target. On the other hand, the Core is very
> lean and low level.
> > Maybe it would be possible to extend the Core set with more ops? For
> example JavaConditionalExpressionOp -> ConditionalExpressionOp.
> > It should be also possible to define a generic version of
> LoopExpressionOp, TryExpressionOp, SwitchExpressionOp, etc. (All these Ops
> can be lowerable to a simpler form)
> > The idea is to have several levels of lowering. For example, JavaForOp
> and JavaWhileOp will lower to LoopExpressionOp first.
> > If the "intermediate" Ops set will be convenient and stable, it will
> allow the analysis libraries to target it in many practical cases.
> >
> > --
> > I understand very well the security consideration of having Quotable
> interface. But it comes with a price of defining another interface and a
> potentially redundant hierarchy as a result.
>
> That’s true, I suspect it will likely be more impactful that serializable
> lambdas.
>
>
> > Just wanted to mention that there might be alternative implementations
> addressing this requirement.
> > 1. Structural quoting (a la C#) - derives from the variable type, e.g.
> Quoted<T>. So, the user understands that the lambda body will be accessible.
>
> There are some challenges with Java’s type system, which is why we
> embedded up where we are with the current approaches. Maurizio is better
> able than I to describe these challenges.
>
>
> > 2. Special annotation applied on the variable or a method parameter.
> >
>
> This is tricky. It’s not actually clear to me yet whether
> `@CodeReflection` on methods is the right way to go. We are skating on thin
> ice, as platform annotations should not change program behavior. We might
> need a contextual key word. Even so it may be a deep cut to apply beyond
> methods declarations themselves, and we would still need to wire up
> reflectable lambda bodies into the type system. (I suspect we are likely
> revisit some of the design discussions on serializable lambdas in that
> respect.)
>
> Probably Quotable should not have any methods on it, and one has to use a
> reflection API to access the quoted instance. Thereby avoiding situations
> where the developer explicitly implements the quotable functional interface
> using a class, from which we may be able to enforce the method
> implementation to be reflectable.
>

All good points. I'm not sure I fully agree with the statement that
`@CodeReflection` on variables changes the program behavior, i.e.
`where(@CodeReflection Predicate<T> f)` and how it is conceptually
different from `where(Quoted<T> f)`, but the most important thing is that
`Quotable` needs some review before GA.

-- 
Regards,
Konstantin Triger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240508/2a73d0a7/attachment-0001.htm>