[armedbear-devel] svn r12228 breaks build

[logicmoo at gmail.com]

> 
> ----- Original Message ----- 
> From: "Alessio Stalla" <alessiostalla at gmail.com>
> To: "Mark Evenson" <evenson at panix.com>
> Cc: <armedbear-devel at 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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel