Symbolic annotation processor

Tue Jun 14 14:45:01 UTC 2016

Bernard,

While the work you describe sounds interesting, as a general rule,
OpenJDK projects are those that are directly or indirectly related
to the ongoing evolution of OpenJDK and what you describe sounds
more like a use of OpenJDK more than anything that might be
contributed to be part of OpenJDK.

-- Jon

On 06/13/2016 03:35 AM, bsrbnd wrote:
> Hi,
>
> As we all know, many numerical methods involve the derivative
> computation of a function; Newton's method to solve a non-linear
> equation, for example.
> Using an imperative language, we would probably compute an
> approximation of the derivative, which could be slow and probably
> inaccurate.
> But with symbolic expressions, we are able to compute the symbolic
> form of the derivative directly, which is much faster and is an
> absolutely correct solution.
>
> I haven't written any example for that yet, but you can refer to John
> McCarthy's paper: "Recursive Functions of Symbolic Expressions and
> Their Computation by Machine, Part I", Massachusetts Institute of
> Technology, Cambridge, Mass., April 1960, chapter 3.g on page 21;
> which can be found at:
> http://www-formal.stanford.edu/jmc/
>
> In addition to previous discussions, this example shows a bit more the
> benefits of symbolic programming.
>
> Notice that I've also updated the genetic programming example
> (presented in the previous email below) to link lambda to symbolic
> expressions and to use the existing functional API.
>
> Do you think it could be interesting to create an OpenJDK project to
> study more about this subject?
>
> Thanks,
>
> Bernard
>
> 2016-04-03 13:16 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> I wrote a simple genetic programming example (a symbolic regression)
>> using SymProc, here:
>> https://github.com/bsrbnd/draft/blob/master/src/examples/GeneticProgramming.java
>>
>> As we can see, symbolic programming could be also the basements for
>> functional programming.
>> Notice, for example, the ease of the computation of the integral of
>> the absolute difference between two functions:
>>
>> private Double fitness(Symbol<?> $f) throws Exception {
>>      return integral(LOWER_BOUND, UPPER_BOUND,
>> $abs.apply($sub.apply($f,$target)));
>> }
>>
>> Regards,
>>
>> Bernard
>>
>> 2016-03-17 12:26 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> After a very fast and superficial reading of the JLS, I wrote some
>>> jtreg tests for points that might be impacted
>>> by the symbolic-processor. Source code of the tests, grouped in two
>>> files for more readability, can be found at:
>>> https://github.com/bsrbnd/draft/tree/master/src/tests
>>>
>>> Some of them show a bit more precisely the benefit of incorporating in
>>> some way the symbolic programming paradigm
>>> (the ability to manipulate the symbols of a language) to enhance the
>>> reflection (and perhaps even more...).
>>>
>>> As generics are earased during runtime, it could be hard to get the
>>> reflective elements of members using generics
>>> heavily (and even harder to maintain).
>>> Consider the following example inspired by JLS8, chapter 4.4:
>>>
>>> class MyTypeVariable {
>>>      public static class C {}
>>>      public static interface I {}
>>>
>>>      @Symbolic private <T extends C & I> void myMethod(T t, T[] u) {}
>>> }
>>>
>>> Without the symbolic view of members, you have to write something like
>>> the following to get the reflective object:
>>> Method m = MyTypeVariable.class.getDeclaredMethod("myMethod",
>>> MyTypeVariable.C.class,
>>> MyTypeVariable.C[].class));
>>>
>>> But, with the symbolic-processor, you delegate the generics and
>>> erasures handling to the compiler:
>>> Method m = MyTypeVariable.$myMethod.reflect();
>>>
>>> This is, of course, easier to write and to maintain.
>>>
>>> I've also tried to go further with this paradigm by introducing
>>> dynamically constructed symbolic expressions
>>> (a bit like LISP does) and evaluate them on a particular instance, for example:
>>>
>>> class DynamicExpression {
>>>      @Symbolic private Integer a = 3;
>>>      @Symbolic private Integer b = 2;
>>>      @Symbolic private Integer c = 1;
>>>
>>>      @Symbolic public Integer add(Integer i, Integer j) {return i + j;}
>>>      @Symbolic public Integer sub(Integer i, Integer j) {return i - j;}
>>> }
>>>
>>> MethodSymbol $symbolicExpression = $add.apply($a, $sub.apply($b, $c));
>>> Integer d = (Integer)$symbolicExpression.evaluate(new DynamicExpression());
>>>
>>> This expression evaluates naturally to 4 for this instance.
>>>
>>> The full running example can be found at:
>>> https://github.com/bsrbnd/draft/blob/master/src/examples/DynamicExpression.java
>>>
>>> Symbolic expressions could be useful for evolutionary algorithms used
>>> in genetic programming, where dynamic
>>> expressions are iteratively crossed-over and mutated to find the best
>>> approximation of a solution.
>>>
>>> I hope that I didn't miss anything in the JLS and that something like
>>> this hasn't already been incorporated
>>> in any existing project.
>>>
>>> Regards,
>>>
>>> Bernard
>>>
>>> 2015-12-10 14:50 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>>> Hi,
>>>>
>>>> Following our discussion (October 2015), I wrote an
>>>> annotation-processor (only a draft for now) that gives a symbolic view
>>>> of class members, for example:
>>>> @Symbolic private Object myField;
>>>> @Symbolic("_") private void myMethod(Object param) {}
>>>>
>>>> We can either access the name or the reflective object of members the
>>>> following way:
>>>> String name = $myField.toString(); // $ is the default prefix
>>>> Method m = _myMethod.reflect(); // _ is a custom prefix, useful for
>>>> overloaded identifiers
>>>>
>>>> You can find a simple example here:
>>>> https://github.com/bsrbnd/draft/blob/master/src/examples/Example.java
>>>>
>>>> Full source code of the annotation-processor prototype is given there:
>>>> https://github.com/bsrbnd/draft
>>>>
>>>> Comments are welcome, but I know this is probably not the right
>>>> mailing-list for that.
>>>>
>>>> Regards,
>>>>
>>>> Bernard