Symbolic annotation processor

[bsrbnd]

With respect to McCarthy's paper, I think that symbolic expressions
are at the heart of functional programming; the key idea being the
manipulation of algebraic formulas.

In his document, functional API and lambda notation come only as
instruments to construct and use symbolic expressions which are
represented by list structures.

But I agree that symbolic functions and expressions rely on
meta-expressions. Thus, in our case, we could see Java as the
meta-language and symbolic expressions as something built above, as
shown by the symbolic annotation processor.
Nevertheless, I consider that it could probably be also fully part of
Java the same way it is at the foundation of the LISP language...

Bernard

2016-06-14 16:45 GMT+02:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> 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
>
>