Re: unimplemented support for compiling gnu.expr.PrimProcedure literals

[Per Bothner <per at bothner dot com>]

"Daniel Bonniot" <bonniot@cma.ensmp.fr> writes:

> I get this warning when I try to compile code (in my language, not with
> Kawa) like f(g), where f is a higher order function, and g is a method
> (hence represented by a QuoteExp(PrimProcedure) during compilation).
> 
> How is this kind of code compiled in Kawa? Maybe there is a workaround.

It doesn't work. I tried compiling the following:

(define (foo f)
  (f (primitive-static-method <java.lang.System> "getProperty"
			      <String> (<String>))))

and got:

<unknown>:0: unimplemented support for compiling gnu.expr.PrimProcedure literals

> Would it make sense to make PrimProcedure implement Compilable? I am willing
> to work on that if this is clear what should be done.

I can see two different solutions:

(1) Have PrimProcedure implement Compilable.  The 'emit' method would
generate code to call some appropriate PrimProcedure constructure.
You then get a PrimProcedure created at run-time;  applying that
PrimProcedure would involve reflection.

(2) Instead of wrapping the PrimProcedure in a QuoteExp, wrap it in an
ApplyExp wrapped in a LambdaExp.  (Actually, you still need to wrap it
in a QuoteExp first. but the ApplyExp constructor does that for you.)
This will cause the compiler to generate inline code for the actual
PrimProcedure, thus no reflection is needed at run-time.

Neither are very complicated.  (1) would be an enhancement to Kawa.
(2) would need to be done by your implementation - but it may make
sense to write a convenience mentod in Kawa that you woudl use.  It
might be nice to have (1), just on the general principle that
PrimProcedure *should* be compileable.  However, (2) is clearly the
better implementation performance-wise.  It might be nice to implement
both (1) and (2), if you have the energy.  Implement first (1), time
it, and then implement (2), and time that - ideally on a couple of
different VMs.  That would give us some useful data on the cost of
various implementations.  Right now, I've made certain implementation
choices, based on my "common sense" understanding of how expensive the
alternatives are, but it would be nice to have data backing this up.
I.e. it would be nice to know whether using reflection is 3 times
slower or 100 times slower!
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/