Add pre-processer into Processing.R

[gaocegege]

ref https://forum.processing.org/two/discussion/comment/90750/#Comment_90750

As for those conflict function names such as line, we could pre-pass all line calls in R mode to processing.line in Java and r$line to standard line function call in R, because I think R mode users call processing built-in functions more often. And if they need to use same name functions in R standard library, r$something works.

Then processing.r has the same behavior as in Java mode, follow the Law of Least Astonishment to more user-friendly, IMO :)

implement the pre-processor to solve the problem

[gaocegege]

See http://stackoverflow.com/questions/2439782/overload-with-different-return-type-in-java

And there is one thing else should be noticed: The implementation of built-in alpha function is tricky, I don't know why I can't define two function:

public double alpha(int rgb) {
}
public float alpha(int rgb) {
}

in one class, javac tells me that they are one function, and it is an override function. It seems that same function name, same parameter lists and different return types is treated as override, not overloading.

Pre-processor should solve this problem.

[jeremydouglass]

Have you looked at the Processing default (Java mode) preprocessor?

https://github.com/processing/processing/tree/master/java/src/processing/mode/java/preproc

I'm not familiar with it but I believe it is based on ANTLR -- quite complex and heavy-duty, but it might give you some ideas for reusing parts or for just making a very lightweight R preprocessing. Once you have studied it if you have questions you could consult with @JakubValtar and @benfry

[gaocegege]

IMO, the goal of pre-processor is to reorganize the code and transfer the syntax sugars to regular syntax. Then we need a tokenizer and a parser to achieve this.

I am not sure if renjin could do that. I will have a look before the implementation.

BTW, processing.py's pre-processor is another way. It parses the AST from the code as the standard python and does some operations in the AST to achieve the same goal.

[jeremydouglass]

Nice example from processing.py's pre-processor. Is there is a similar AST library approach available for Java? That might work. If I understand you, the single biggest pre-processor issue right now is identifying a list of implemented functions functionName and adding processing$functionName. After that, the logic for moving contents of setup() and settings() in P3 (which processing.py demonstrates). After that, color.

If I'm understanding the big problem correctly, renjin parses R for JVM -- because it isn't "translating R into Java" there is no way to simply use these aspects of Processing's Java pre-processor. This would be ideal, but is impossible.