[armedbear-devel] [PATCH] jcall(there are multiple matchingmethods)
ehuels at gmail.com
Tue Dec 22 20:56:46 UTC 2009
On Tue, Dec 22, 2009 at 9:54 PM, Alan Ruttenberg
<alanruttenberg at 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.
> On Tuesday, December 22, 2009, Tobias C. Rittweiler <tcr at 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)]
>> Sounds like a nice project for the free time between the years.
>> Any takers?
>> armedbear-devel mailing list
>> armedbear-devel at common-lisp.net
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
More information about the armedbear-devel