This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Question on compiling to bytecode
Erol Akarsu wrote:
As Per mentioned, bytecode optimization may be not efficient because we may
not see global picture of source code. I have just quickly checked Jscheme
is generating Java source file, jython does also.
That is a disadvantage, not advantage, of those systems - it makes them
much less responsive. Either that, or they have to have a separate
interpreter that duplicates the compiler logic. Systems that emit
Java rather than bytecode do so because it easier, not better.
I think a Scheme compiler should do.
No, I disagree..
As a result, we will benefit the strength of both functional,
compiled and interpreted environments,
I have no idea what a "function environment" or an "interpreted
environment" is. I prefer the term "interactive" to indicate the
situation when fresh expression are fed to the system, and a
user is waiting for a response.
that will empower the e-business
software.
Clearly given a choice between compiling to bytecode or compiling
to Java, the former is much more flexible. It makes it practical
to use a compiler in "interactive environments" as Kawa does.
There are other advantages of compiling to bytecode: better
exception traces, debuggers can break on correct line numbers,
can make use of byteoce features (e.g. goto) not available
to source code.
Another example is how Qexo uses jsr/ret to implement 'for'
expressions. This trick cannot be expressed in Java.
Because bytecode can express things that Java cannot, you can
actually get better optimization using bytecode rather Java. It
is just the Java-to-native compiler has to work harder. So
improve the latter.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/