[armedbear-devel] [PATCH] jcall(there are multiple matchingmethods)

[Alessio Stalla]

On Tue, Dec 22, 2009 at 10:07 PM, Tobias C. Rittweiler <tcr at 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