[armedbear-devel] svn r12228 breaks build

[Alessio Stalla]

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.
>
> 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.

I agree about separating the two issues. I too believe static imports
should in general be used sparingly to avoid confusion. 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.

Alessio