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.