Alessio Stalla writes:
The point is that classloaders already work like this! When classloader X loads a class, and that class refers to class C, X is asked by the JVM to load C as well. In abcl we are not using this feature, rather we use an ad-hoc loading model that needs temporary files. I propose to replace that completely and adopt the JVM way.
Ok, I think I finally understand all you said initially. I'm sorry to have put you to so much trouble explaining it. I hope a few others will benefit from this explanation.
... However note that your example will probably be compiled by abcl into a call like G.getSymbolFunction().execute(x)
Ok, that's a reasonable escape hatch.
i.e. G will not be resolved to a class at compile time (else how would you handle redefinition?). However, what I'm talking about is (compile 'f (lambda (x) (flet ((g (k) k)) (g x)))) - here g is known at compile time, and compiled to its own class.
(I understood that. The question above was a new one that arose in my mind from what you had been describing.)
What I propose is this: suppose f is compiled to a class named foo41 and g to foo42, then in one of foo41's methods you'll have code like LispObject g = new foo42(). When loading foo41 we'll use our abcl-specific classloader which knows how to resolve foo42 too (because it knows where to read it from memory or from the file system, depending on the type of compilation), and everything magically works (I hope :)
Sounds plausible but I can see why you say you hope. Good luck. And thanks for your patience.