On Tue, Dec 22, 2009 at 10:07 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
Alan Ruttenberg writes:
This would be incompatible with other common lisps, and make porting to other java enabled lisps in the future a pain. My gut says don't mess with the define reading behavior.
I can't follow that line of logic; which other java-enabled Lisps of the future are you talking of?
Why should ABCL care for java-enabled Lisps of the future? It should become the java-enabled Lisp of the future: i.e. ABCL should strive to become a hallmark for java integration.
The problem are not Java-enabled Lisps of the future, it's messing with CL semantics!
In CL (symbol-function 'foo) is defined to signal an error if foo is not a function. If you use Lisp symbols to represent Java methods this is not true anymore. This is just an example, many other parts of the language would possibly be interested.
I have no problems with (jmethod 'foo), say, to return a closure that when invoked will dispatch on foo. But that's entirely another story. What even *may* not clash with CL (but we should consult a language lawyer) is for a form like (#<jmethod foo> args) to invoke the method, i.e. if Java methods were funcallable objects. Still, using special syntax for methods is the only way (that I can think of) to extend ABCL in order to support jmethod literals and still be standard Common Lisp.
Just my € .02, Ale