Notations for calling Java methods

[Duncan Mak]

Hello Per,

I was doing some reading on the various Scheme implementations on the JVM
and saw that both JScheme and SISC and of course Kawa have their own way to
reference Java fields/methods.

Kawa - https://www.gnu.org/software/kawa/Method-operations.html

JScheme - http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html

SISC - http://sisc-scheme.org/manual/html/ch08.html#SchemeToJava

I was wondering if you could say more about the variously notations, and
their pros and cons - is there a reason why Kawa did not adopt the Javadot
notation?

Also, I saw that Silk has another technique (
http://www.cs.brandeis.edu/~tim/Papers/Reflection99/Old/paper2.html), and
what do you think about that?

Thanks!

[Per Bothner]

Post by Duncan Mak
I was doing some reading on the various Scheme implementations on the JVM
and saw that both JScheme and SISC and of course Kawa have their own way to
reference Java fields/methods.
...
I was wondering if you could say more about the variously notations, and
their pros and cons - is there a reason why Kawa did not adopt the Javadot
notation?

It's been so long ...

I was never fond of javadot notation - it seemed a bit ad hoc - not to say ugly.
The "colon notation" was relatively late - there were various earlier notations,
including a variation of colon notation with special "magic" (ugly ...) characters:

(*:method-name instance argument ...)

as opposed to the now-preferred form:

(instance:method-name argument ...)

Looks like the "colon notation" as a separate section of the manual is from 2011,
but I believe the implementation is older than that: The class GetNamedPart (used
to represent colon notation) is from 2005.

Post by Duncan Mak
Also, I saw that Silk has another technique (
http://www.cs.brandeis.edu/~tim/Papers/Reflection99/Old/paper2.html), and
what do you think about that?

I'm leary of Silk's (import CLASSNAME). It defines imported methods as generic functions,
which seems a bit dangerous and prone to mysterious name clashes.

Note also that a key goal of Kawa is to support efficient compilation: you generally
don't want to use reflection. Instead Kawa tries to compile to bytecode similar
to what javac would emit.