Trying to work newer indy into JRuby

[John Rose]

On May 19, 2009, at 1:00 AM, Rémi Forax wrote:

> The purpose of primitive adapters is to hep the language developer  
> to fight
> the inherent complexity of dealing with polymorphic signature.

Yes, that's the key point.

As Fredrik says, you can hide the polymorphism by going to a  
reflective (fully boxed) calling sequence.  But, we've had 10 years to  
learn to optimize that reliably, and we don't.  Some JVMs optimize  
boxing sometimes, but not all do, and it is historically a hard  
problem.  A goal of the present design is for the new facilities to  
support the full range of JVM calling sequences, including native  
(unboxed) primitives.

The set of combinators in MHs is not minimal, but it is only a step or  
two away (I hope) from being tasteful.

If a JVM has excellent boxing analysis, then it can implement these  
combinators very easily on top of Lisp-y rest-args.  But we can't  
presume that for all JVMs.

The combineArguments combinator is both polymorphic and pretty nearly  
universal (without boxing).  I hope to implement it mostly "in the  
metal", under the name "flyby adapter".  The idea is you get a  
subroutine to witness the full argument list and make some  
computation, the result of which is injected back into the argument  
list before the ultimate target is called.  If the injected value is  
itself a method handle, and the ultimate target is MH.invoke, then we  
have the makings of a threaded interpreter, all inside a method handle  
nest.  Therefore, inlinable in the LLVM sense.

I expect to implement guardWithTest on top of combineArguments.

-- John