Hi. Thank you pointed out. I changed the patch. Regards, -- Yoshinori Tahara 2009/11/7 Alessio Stalla <alessiostalla@gmail.com>:

On Sat, Nov 7, 2009 at 2:34 AM, Yoshinori Tahara <read.eval.print@gmail.com> wrote:

...

Hello.

Attached is a patch which fixes jcall in case there are multiple matching methods.

Hi. I have written very similar code (in Lisp) for a project of mine. However, I think that it's incorrect to just return the first applicable method, as there can be multiple ones, and you should choose the most specific. Anyway, your patch is a good start.

Bye, Alessio

To me the .patch looks correct. Good work Yoshinori ----- Original Message ----- From: "Alessio Stalla" <alessiostalla@gmail.com> To: "Yoshinori Tahara" <read.eval.print@gmail.com> Cc: "Armed Bear" <armedbear-devel@common-lisp.net> Sent: Thursday, November 12, 2009 12:54 AM Subject: Re: [armedbear-devel] [PATCH] jcall(there are multiple matchingmethods)

On Thu, Nov 12, 2009 at 9:34 AM, Yoshinori Tahara <read.eval.print@gmail.com> wrote:

...

Hi. Thank you pointed out. I changed the patch.

Hi, nice! Thank you very much for your contribution! I'm positive about committing it to trunk. What do other people think?

Bye, Alessio

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

On Mon, Nov 23, 2009 at 2:47 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:

On Mon, Nov 23, 2009 at 2:24 PM,  <logicmoo@gmail.com> wrote:

...

To me the .patch looks correct.

Good work Yoshinori

Good work indeed. Since no-one said anything against the patch I'll commit it as soon as possible (this evening, probably).

It took way longer than I had foreseen, but I've finally committed your patch. Now jcall can be used with less verbose syntax, for example: (jcall "toString" 4) ==> "4" (jcall "compareTo" 4 5) ==> -1 it would be nice to add (#"methodName" args) a la JSS for even shorter syntax. Bye, and thanks for your patience, Alessio

On Tue, Dec 22, 2009 at 9:05 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:

Alessio Stalla writes:

...

On Mon, Nov 23, 2009 at 2:47 PM, Alessio Stalla wrote:

Now jcall can be used with less verbose syntax, for example: (jcall "toString" 4) ==> "4" (jcall "compareTo" 4 5) ==> -1

it would be nice to add (#"methodName" args) a la JSS for even shorter syntax.

FWIW, I do not like the special read syntax. I think, the real solution that ABCL should strive for is

 - to implement per-package symbol case sensitivity a la Clisp

   See  http://clisp.cons.org/impnotes/package-case.html

 - introduce a package JAVA (with nickname J) where symbols are    interned in while preserving case.

Ultimatively, ABCL should strive for making

 (funcall j:compareTo 4 5)  [read in as (FUNCALL J:|compareTo| 4 5)]

work.

I assume you mean (funcall (quote j:compareTo) ...), and if we had that, also simply (j:compareTo ...) For that to work, we should alter the semantics of the language quite dramatically, and I'm not even sure the result would be CL anymore. E.g. (let ((fn (symbol-function 'j:someMethod))) ...much later... (funcall fn some-obj)) should be possible, but in that case the unbound function (or method not found) error can only be signaled at the time of the funcall, since the existence of the method can only be determined given the argument types. I don't think such dramatic changes would buy us anything good. If you want to pass around Java methods like they were closures, you can simply wrap the call in a lambda and pass that. You could even write a jlambda or something macro to create the closure for you. Alessio

On Tue, Dec 22, 2009 at 10:03 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:

Alessio Stalla writes:

...

I assume you mean (funcall (quote j:compareTo) ...), and if we had that, also simply (j:compareTo ...)

For that to work, we should alter the semantics of the language quite dramatically, and I'm not even sure the result would be CL anymore. E.g.

(let ((fn (symbol-function 'j:someMethod)))   ...much later...   (funcall fn some-obj))

should be possible, but in that case the unbound function (or method not found) error can only be signaled at the time of the funcall, since the existence of the method can only be determined given the argument types. I don't think such dramatic changes would buy us anything good.

Why can't it signal an unbound function error?

Because later you might find that the user actually referred to a Java method, not a Lisp function. You could limit this behavior just to symbols in the j package, but it would still be an inconsistency with CL, besides smelling like a hack.

The existence of methods is checked at call time for generic functions as well. If it does not exist, an no-applicable-method error is signalled.

Yes, but generic functions are required to be defined before calling symbol-function to avoid getting an error. Java methods cannot satisfy this requirement[*]. If symbol-function cannot anymore signal an undefined function error (at least for some symbols), what about fboundp? Should it always return T for those symbols? What about (defun j:something () ...), i.e. redefinition? What about symbol visibility: are all symbols in j automatically exported so I can write j:foo for any foo? Etc. etc. Too many special cases and deviations from CL for my tastes. A. [*] We could require Java methods to be declared as well: (define-jmethod foo "com.xxx.Bar.baz"). It doesn't even require modifying anything in the language, just have define-jmethod be a macro expanding to defun. But we would lose all the convenience.

On Wed, Dec 23, 2009 at 8:52 AM, Tobias C. Rittweiler <tcr@freebits.de> wrote:

Alessio Stalla writes:

...

Too many special cases and deviations from CL for my tastes.

-I- haven't spoken about deviations.

Not directly, but you have implied them with your proposal, in my opinion. Correct me if I'm wrong.

...

[*] We could require Java methods to be declared as well: (define-jmethod foo "com.xxx.Bar.baz"). It doesn't even require modifying anything in the language, just have define-jmethod be a macro expanding to defun. But we would lose all the convenience.

I'm not talking about replacing the JMETHOD etc primitives; I'm talking about leveraging the package system as a means of integration rather than using a reader macro.

I haven't talked about replacing JMETHOD & friends either; my point is just that by "leveraging the package system..." you obtain a new language which is not standard Common Lisp anymore. If you don't agree, prove how (apply 'j:foo args) => something is conformant to the CL standard when j:foo does not name a Lisp function.

The benefits are that it allows the user to customize integration in a fine-grained way, and it provides for smoother integration (and by that merit, is more "Lispy".)

It's more about integrating Lisp and Java packages. That's the real problem to tackle (and it, as far as I see, subsumes method lookup.)

To integrate Lisp and Java packages is a different thing, very loosely related to method lookup in my opinion. First, Lisp packages are namespaces: in Java a namespace is either a package or a class. Also Java is like Lisp-2, i.e. the same symbol can name both a field and a method. One naive way to integrate them would be to have one Lisp package per Java package, containing symbols naming Java classes, and one Lisp package per Java class, containing symbols for Java fields and methods. Another, probably more sensible approach could be to just have a Lisp package per Java package and devise some naming scheme so that the symbol foo.bar in package baz names the member bar in class foo in package bar. There are other possibilities as well, but in any case you can't make the Common Lisp reader act specially on symbols in a certain package. You'd need either to iterate over the whole Java classpath and create all the packages and symbols at once, or have the user explicitly declare them, e.g. (jimport "com.foo.Bar") could create a Lisp package com.foo if it doesn't exist yet and put a symbol Bar in it and symbols Bar.xxx for all the members of Bar. jmethod and friends would then recognize those symbols (for example looking for a property in their plist) and act accordingly. I'm not sure I'd want to use something like that, but it's just an extension, so I'm not against it in principle. Alessio

On Tue, Dec 22, 2009 at 9:54 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

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.

We could look at the way CCL (Clozure) integrates with Cocoa: it uses a special syntax to identify foreign calls too. That would be a nice way of integrating; besides: that kind of macro character would defacto be unuseable anyway: CCL has a defined purpose for it already. Regards, Erik

-Alan

On Tuesday, December 22, 2009, Tobias C. Rittweiler <tcr@freebits.de> wrote:

...

Alessio Stalla writes:

...

On Mon, Nov 23, 2009 at 2:47 PM, Alessio Stalla wrote:

Now jcall can be used with less verbose syntax, for example: (jcall "toString" 4) ==> "4" (jcall "compareTo" 4 5) ==> -1

it would be nice to add (#"methodName" args) a la JSS for even shorter syntax.

FWIW, I do not like the special read syntax. I think, the real solution that ABCL should strive for is

  - to implement per-package symbol case sensitivity a la Clisp

    See  http://clisp.cons.org/impnotes/package-case.html

  - introduce a package JAVA (with nickname J) where symbols are     interned in while preserving case.

Ultimatively, ABCL should strive for making

  (funcall j:compareTo 4 5)  [read in as (FUNCALL J:|compareTo| 4 5)]

work.

Sounds like a nice project for the free time between the years.

Any takers?

  -T.

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

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