Symbolic annotation processor

bsrbnd bsrbnd at
Mon Jun 13 10:35:55 UTC 2016


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
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:

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?



2016-04-03 13:16 GMT+02:00 bsrbnd <bsrbnd at>:
> Hi,
> I wrote a simple genetic programming example (a symbolic regression)
> using SymProc, here:
> 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>:
>> 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:
>> 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:
>> 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>:
>>> 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:
>>> Full source code of the annotation-processor prototype is given there:
>>> Comments are welcome, but I know this is probably not the right
>>> mailing-list for that.
>>> Regards,
>>> Bernard

More information about the compiler-dev mailing list