[armedbear-devel] 0.18 and beyond

[logicmoo at gmail.com]

----- Original Message ----- 
From: "Ville Voutilainen" <ville.voutilainen at gmail.com>
To: <swank.matthew at gmail.com>
Cc: "Armed Bear" <armedbear-devel at common-lisp.net>
Sent: Friday, November 06, 2009 8:12 AM
Subject: Re: [armedbear-devel] 0.18 and beyond


2009/11/6 Matthew D. Swank <akopa at charter.net>:
> Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
>> I don't believe we want to convert lisp code to java code in the
>> future. The ongoing desire
>> is to have less java and more lisp.

A big reason I was suggesting

 .lisp-> .class -> .java

Would be to discover and remove any/all LispInteger/Finxums that have somehow
snuck into the bytecode.

 Since something like the core library code should be free for these things
  until we can get the compiler not to produce them.

Of course it's silly to expect the compiler to ever get rid of all Fixnums from generated bytecode :)

But I wanted to sound absurd right there.. here is why:



Take the output of a different lisp compiler of "format.lisp" into java..

http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/tool/subl/jrtl/translatedCode/sublisp/format.java?revision=254&view=markup&pathrev=254

Look at line 930  with horror as you can see how very far away it is from doing the right thing.
you'd expect  it to read instead as:  for(int i=0;i<scale;i++)
If this was a critical function .. you'd think they'd go back in rewrite it better.

ABCL's compiler lets hope doing _way_ better than this..
Imagine if it had places it wasn't?!!
How much efficient could the core libraries could be
If after the initial lisp->class->java some hand attention was given?

If we found out the bytecode emitted Lisp.readFromString(..)?
Would we leave it like that?

Now realistically only when needed. and very important parts of the core.
Since every compiler improvement will regenerate a new "lisp->class->java"
The hand improvements should be allot less each time.

Erik often inspects the bytecode in the disassembler to make sure its at least reasonably sane.
On many levels each compiled Primitive is pretty ok..
Once they are generated into an "app" sometimes might need to be looked out with more sets of human eyes.
And the compiler reworked until and reworked until eventually the human eyes are no longer needed.