----- Original Message ----- From: "Alessio Stalla" alessiostalla@gmail.com To: "Mark Evenson" evenson@panix.com Cc: armedbear-devel@common-lisp.net Sent: Monday, November 30, 2009 2:31 AM Subject: Re: [armedbear-devel] svn r12228 breaks build
On Mon, Nov 30, 2009 at 10:25 AM, Mark Evenson evenson@panix.com wrote:
svn r12228 breaks the ABCL build pretty badly, with (at least) mention of the non-existent 'LispTrampolinesFile', although there are other errors that may/or may not be corrected by the addition of this missing file.
I am neutral with the intent of the patch to introduce static imports for Lisp.java, although as I understand it this is merely a cosmetic change as it doesn't change the generated bytecode. The use of the wildcard import bothers me a bit as the intent of the linkage is then implicit rather than explicit, but in truth this loses no more information that a call to "Lisp.foo()". I find I tend to get confused about where the symbol is coming from (is it inherited? is it from the import?), but maybe I am getting old and grumpy.
The question was how did you tell where "foo" it was comming from before?
It seems that Lisp.foo() is best for way to denote the method came from Lisp. It maybe should have been that way all along.. I think the reason it wasnt was to keep the size of the source code down.
But as to the use of a trampoline, the last time I understand the proposal from David Miles, I was definitely against as requiring a lot of rather ugly looking boilerplate code to every Primitive without providing anything substantial in return. I admit that would need to re-study David's proposal a bit to come up with more concrete arguments, but at the level I understood it my negative assessment could be summarized by: maintaining the trampoline linkages would be a good candidate for an automatic tool with access to the Java AST. Without such a tool, we end up creating more work to maintain/undestand the source.
Therefore, I would advocate reverting svn r12228 for the time being, and at least separating the two issues of the static wildcard import of Lisp.java from the introduction of LispTrampolineFile.java.
LispTrampolineFile.java is just a stub that the current Trampolines extend.. It just was missed in the r12228 commit
The file simply contained =================================== package org.armedbear.lisp;
abstract public class LispTrampolinesFile { } =================================== As a historical placeholder for when the trampolines that have always been in ABCL extended Lisp that no longer do. Nothing would need to go into that file. It probably should have been an interface if anything at al.
I agree about separating the two issues. I too believe static imports should in general be used sparingly to avoid confusion.
Yes, in the patch being explicit about imports.. was considered but then decided to use wildcard to make it smaller. its a good idea to make them explicit.. just was trying to keep the size of the .patch down.
So one exmaple in CharacterFunctions.java hwere is says:
import static org.armedbear.lisp.Lisp.*;
would become
import static org.armedbear.lisp.Lisp.error; import static org.armedbear.lisp.Lisp.type_error; import static org.armedbear.lisp.Lisp.T; import static org.armedbear.lisp.Lisp.NIL;
etc
As for the static trampolines requiring manual maintenance, see my 11/11 mail w/ attached patch that uses Java reflection to hide much of the plumbing (and additionally reduces the number of classes from one per primitive to one plus a few possible special cases). I'm not advocating it as the perfect solution but I think it's good enough for general use, and can be introduced incrementally (i.e. we don't have to replace all the primitives at once). Also it's not significantly harder to read, provided that the static method(s) are defined textually close to the primitive and not in a single catch-all Trampolines class.
Yes, thanks for clearing that up.
Alessio
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel