Enhancing expressions with mutability?

[Maurizio Cimadamore]

> I'm planning to employ experimentally to solve some
> tricky performance issues in javac's type inference solving system,
> see [3].

With respect to implement type inference using these algorithms, I feel 
less sanguine. While theoretically possible, genetic algorithms usually 
goes through making random variations in a set of values, and 
iteratively keeping the values that fit best a given scoring function. 
Yes, we can define the scoring function to be "does the solution satisfy 
the bounds" - but getting there by randomly changing variable resolution 
until you find "one that sticks" doesn't seem amenable in the general 
case, although I can definitively buy that, in _that specific example_ 
you refer to, doing things that way is faster than doing things how 
javac does it (which is wildly suboptimal - hence the bug). There are 
also other assumptions in your prototype that are, I think, too 
simplistic - e.g. the fact that you can replace subtyping with 
subclassing (the latter is of course much faster, and has many many less 
degrees of freedom) - and, while a strategy like this might converge 
quickly to a solution, when writing a static compiler is also very 
important to take into account the case where no solution exists (e.g. 
compiler error) - do I have to wait forever until all possible 
permutations are ran? How will error messages be reported (or even 
determined)?

So, while expression-tree-like approaches are very powerful and 
expressive, I think that a properly implemented and optimized type 
inference algorithm will always provide better and more predictable 
performances in the general case.

>>> 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?
Whoops - yes!
> Great, are you planning to do this as part of an existing project like
> Panama or are you going to create a new one?

At this moment we're exploring what's available out there - we have some 
ideas of the use cases we'd like to cover, but no specific proposal as 
of yet. While it's true that some of the core use cases are close to the 
spirit of Panama, some of the applications are also much broader - so I 
can see this going both ways. In any case, it's way too early to make 
such a call :-)

Maurizio

>
> Ciao,
> Bernard
>
>>> Maurizio
>>>
>>> [1] - https://urldefense.com/v3/__https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/__;!!GqivPVa7Brio!NfcoHAGJenwaQiTQ8X9WraJnbuoptP3p-CDxaw9iRIV0u9WCJI8z_RuUJLBrpHWd0BFKVWs$
>>>
> [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