Re: Question on compiling to bytecode

[Erol Akarsu <eakarsu at cmguc dot com>]

Hi Per,

I appreciate your comments. I benefit really.
I need to run some scheme programs with using Kawa and GCJ and see results. By
the way, do you have some examples I can use immediately for this? Probably, I
will compare the runtime of scheme executable coming from Kawa&GCJ and Bigloo
and see they are close to each other. It seems very attractive that Kawa can
provide seamless access to Java and C++ through GCJ. I would like to use huge
investment done with Java and C++.

Debugging is very important. How can Kawa solve this debugging issue? Can It
provide to debug Scheme source file?

Thanks

Erol Akarsu

Per Bothner wrote:

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