Re: [armedbear-devel] Using named classes for primitives
On Mon, Oct 19, 2009 at 2:59 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Mon, Oct 19, 2009 at 2:22 PM, Alex Muscar <muscar@gmail.com> wrote:
Hi,
I've been messing around with the code. I've managed to load the fasl, but I think we're missing some initializations because I get the following error:
ERROR placeholder called with arguments: #<UNDEFINED-FUNCTION SYSTEM::ENSURE-AVAILABLE-SYMBOLS {E5F46E}>
Here's a full stack trace:
org.armedbear.lisp.ConditionThrowable: java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1459)
OT, but not too much: if we used named classes for primitives we could get more meaningful stack traces (say, JCALL instead of Primitives$XY). I.e. instead of
private static final Primitive xyz = new Primitive(...) { ... };
we could use
private static class JCALL extends Primitive { JCALL(...) { super(...); } ... } private static final Primitive xyz = new JCALL(...);
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-) Bye, Erik.
Erik Huelsmann writes:
On Mon, Oct 19, 2009 at 2:59 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
private static final Primitive xyz = new Primitive(...) { ... };
we could use
private static class JCALL extends Primitive { JCALL(...) { super(...); } ... } private static final Primitive xyz = new JCALL(...);
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-)
If someone does, it may make sense to also include source location information to make M-. on primitives jump to the Java source. I actually started to work on it, but haven't had any time since. -T.
On 10/19/09 5:48 PM, Erik Huelsmann wrote: […]
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-)
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing, but it seems a little neglected since 2007 so it won't easily run in a modern IDE. Interestingly it has an "add overrides" example that would have helped out adding all the override statements. [1]: http://jackpot.netbeans.org/ [2]: http://hg.netbeans.org/main/contrib/raw-file/tip/jackpot/src/org/netbeans/mo... There appear to be 768 instances that need transformation, so the task is indeed suitable to use some sort of automatic tool. I'd give this a whack but I simply don't have extra time until the end of October due to work constraints. I would make the following suggestions if someone else takes on this task: 1) We should name the functions in all lowercase in analogy to the various "standalone" extensions of Primitive like 'open_stream_p.java', 'make_array.java', etc. This produces a more readable stack trace in my opinion. 2) Don't forget to retain the comments with the '###' string in them: they form the necessary linkage for SYSTEM::GROVEL-JAVA-DEFINITIONS 3) Use a no argument constructor in the primitive that calls the appropriate super with the arguments, e.g. // ### packagep // packagep object => generalized-boolean private static final Primitive PACKAGEP = new Primitive("packagep", "object") { @Override public LispObject execute(LispObject arg) throws ConditionThrowable { return arg instanceof Package ? T : NIL; } }; becomes // ### packagep // packagep object => generalized-boolean private static final Primitive PACKAGEP = new packagep(); private static class packagep extends Primitive { packagep() { super("packagep", "object"); } @Override public LispObject execute(LispObject arg) throws ConditionThrowable { return arg instanceof Package ? T : NIL; } }; -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson writes:
2) Don't forget to retain the comments with the '###' string in them: they form the necessary linkage for SYSTEM::GROVEL-JAVA-DEFINITIONS
You don't need that if you store source-location information inside each Primitive object. -T.
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST: http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html At the moment, that's read-only access, but I wouldn't be surprised if that restriction will be lifted at some point in future. And we all know what this will mean: Java gets macros in disguise. :-) Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility... -T.
"Tobias C. Rittweiler" writes:
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST:
http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html
That url linked to the Compiler API, here the direct link to the Compiler Tree Api: http://java.sun.com/javase/6/docs/jdk/api/javac/tree/index.html -T.
On Tue, Oct 20, 2009 at 9:02 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST:
http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html
At the moment, that's read-only access, but I wouldn't be surprised if that restriction will be lifted at some point in future. And we all know what this will mean: Java gets macros in disguise. :-)
I believe C# sort of has them already now... ;)
Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility...
I haven't yet understood exactly what invokedynamic is; would it be helpful for abcl?
Alessio Stalla writes:
Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility...
I haven't yet understood exactly what invokedynamic is; would it be helpful for abcl?
My understanding is based on 5 minutes reading about it, so take it with a grain of salt. From my understanding, when using invokedynamic, code is compiled to something like (transliterated to Lisp): (defun foo (x y) (declare (type t x y)) (check-type x integer) (check-type y integer) (+ x y)) I.e. types are checked at run-time, but the code following the type checks is compiled with the assumption of the type-checks. In the example, the call to + may assume that X and Y are in fact integers, not just any objects. -T.
participants (4)
-
Alessio Stalla -
Erik Huelsmann -
Mark Evenson -
Tobias C. Rittweiler