Symbolic annotation processor

[bsrbnd]

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