Enhancing expressions with mutability?

[B. Blaser]

Thanks for your feedback, Paul and Maurizio.

On Mon, 23 Mar 2020 at 17:00, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
> Hi,
>
> Yes, interesting stuff.
>
> I agree with Maurizio here, naturally because we have talked about this area a few times.
>
> C# expression trees and LINQ is a great example. I think we can apply this more broadly to source compile time, link time and runtime, and more broadly to the source that can be “quoted” (or target typed, rather than built programmatically).
>
> Such an IR could be an interchange format between various domains.  A significant challenge is to find the right structural form to support many use cases. The machine learning area is particularly interesting to me in this respect.  There appears to be an explosion in bespoke static compiler pipelines and analysis of code.
>

I agree that finding the right design is a challenge. I chose the very
flexible approach of Lisp-like S-Expressions, but C# offers
interesting more restrictive expression trees too which seem to be
used in dynamic queries, for example (as I suggested in [2]). But
another common use would be for AI in general like evolutionary
computation that I'm planning to employ experimentally to solve some
tricky performance issues in javac's type inference solving system,
see [3].

> Paul.
>
> > On Mar 23, 2020, at 7:31 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> >
> > Hey Bernard,
> > cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac.
> >

I believe this is the first class of the initially attached
'quote.patch' [4] (next are javac changes along with the test), did
you miss it?

> > That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1].
> >

I'm not so familiar with C# but some difference I can immediately see
is that expression trees seem to use some static typing discipline
which prevents them from being modified directly (new ones have to be
created). My suggestion is closer to Lisp's S-Expression using a more
relaxed dynamic typing discipline enabling full manipulation of
existing expressions.

> > Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to:
> >
> > * regular bytecode - e.g. to generate a method handle
> > * assembly - very useful for native interop (a la Panama)
> > * GPU kernel - very useful for offloading computation to GPU or other resources
> >
> > At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning.
> >

Yes, my prototype currently relies on reflection to evaluate
expressions but the perfect solution would be to ask the JVM to
compile them, of course :-)

> > So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-)
> >

Great, are you planning to do this as part of an existing project like
Panama or are you going to create a new one?

Ciao,
Bernard

> > Maurizio
> >
> > [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/
> >

[2] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014340.html
[3] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014377.html
[4] https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200310/54c5274c/quote-0001.patch