Re[2]: RTL/tree (from gcc) and Scheme

["Valery A.Khamenya" <khamenya at mail dot ru>]

Hello Per,

Sunday, August 10, 2003, 9:06:39 PM, you wrote:

PB> I know the real definitions used within the GCC community.

that's more then good.

>> I am just wondering: R5RS has nothing to say about compilation. There
>> is even no any meaning for this.

PB> That is because compilation is an implementation technique.
PB> A standard should not talk about implementation, only behavior.

Sure. Hey, look at least you don't need to waste your time to explain
me that! :-)

PB> Not every eval - just the non-trivial ones.  It does not compile
PB> a function application - but it does compile a function definition,
PB> including lambda expressions and let expressions.

hm... still, what does mean "just the non-trivial ones"?

PB>  > it would be not that bad!

PB> It's not bad at all - it works very well and fast.  The Kawa compiler
PB> is quite fast, and it generates bytecode directly into memory, which
PB> it loads using a ClassLoader.  So while the overhead is high compared
PB> to just doing the evaluation, in practice it doesn't matter.  Of course
PB> if you're calling eval on non-simple expressions inside an inner loop
PB> then performance may suffer.  But that's a dumb thing to do if you
PB> care about performance, so it doesn't matter.  I haven't measured
PB> the overhead of using the compiler, but it is clearly "plenty fast
PB> enough" that there is no point in maintaining a separate interpreter.

hmm, after reading this I've tried to get last release under cygwin
first. This:
ftp://ftp.gnu.org/pub/gnu/kawa/kawa-1.7.tar.gz ,
ftp://ftp.gnu.org/pub/gnu/kawa/kawa-1.7.jar and this
ftp://ftp.gnu.org/pub/gnu/kawa/kawa-1.7-src.zip are not accessible
for me at least. :-(

>> that's right. Trees and RTL are used for *compile-time* only now.
>> And here came my question: is it really *impossible* to change thing
>> and use RTL/tree in run-time?

PB> Of course it's not impossible.  But what's the point?  What do you
PB> mean by "using RTL/tree at run-time"?  What are you trying to do?

There is a plenty of reasons. Let's just consider main things.

1. Power of portability.

   gcc is extremely portable. Does history know something as portable
   as gcc today? This power of portability belongs just to C/C++,
   FORTRAN and a few other newly introduced languages. What about
   other languages?
   
2. Power of performance.

   I've used C, then C++. I don't love them already. I just can't work
   without them. But, I know a lot of much more promising languages.
   Today, those languages are outsiders. Some of those
   "outsider"-languages are not used widely because of killing factor
   Nr.1: 
   
     "Huh, gcc is n-times faster then this modern language!"

   Users just refer to a particular language implementations not to a
   language itself! And mature GCC wins this race easily. Just because
   it has older and maturer back-end.

   Some of those languages trying to survive using GCC and C/C++ as a
   interface for final compilation to a native. But mostly those
   imperative language belongings to Algol's family can't provide
   to user something really more interesting then C/C++ does.
   (However some of those languages really can. Like Scheme, CL, and
   some others.)

   Well, they die before being born. This can't be forever.

3. Exclusive features like "compile to native in run-time".

   Some functional and dynamically typed languages like ComonLisp are
   able to use "compile to native in run-time" in very advanced
   manner. And it is something more then just cout into a file with
   commandline invocation of gcc for the given code. (Just think of
   event dispatcher function which adapts to an environments and
   starts to check more frequent event earlier then more rare events.
   What about recompile this critical function every second?..)

   There are only few CL implementations able to do this like that:
   
   Allegro CL (commercial, portable but very expensive).
   Lispworks  (commercial, portable but expensive)
   CMUCL      (free, but not portable)
   SBCL       (free, but not portable)

4. Ability to effectively implement new languages using existing
   mature intermediate semantics level.

   I don't know how much time CMUCL and SBCL guys will spend on
   porting to win32, but, maybe, it's better to learn something from
   this very elongated porting.
   
   
>> Some languages could take a new breath just because of this
>> exported service! 

PB> But you haven't explained what the "exported service" would be and
PB> what it would be used for.

what should I add to the 4 issues above? Of course there are more
points, but let's try to keep this important argumentation in focus
without blurring. 

>> BTW, Per, did you get a moment to take a glance at Bigloo?
PB> I'm aware of it and have glanced at it.  Bigloo is a nice Scheme
PB> implementation and compiler.  Note that Kawa is more general, as it
PB> supports multiple programming langauges, including Emecs Lisp,
PB> XQuery, and Common Lisp (though the latter is too incomplete
PB> to be useful).

I do hope I spend my time not in vain. There are not that much people
able to move things like you can. I guess, you felt already that RTL
is tooo much close to Scheme and it is a big mistake just to ignore
this benefit and not to implement Scheme based on it. (Maybe it was
just one of motivations for you to implement kawa?)

BTW, are you still along working on kawa?

P.S. to other responders, I am really sorry, that I am not able to
     response immediately to your mails!

P.P.S. Time in Germany is close to midnight already but I hope to get
     some answers to this email today :-)

Have a nice day!
-- 
Best regards,
Valery                            mailto: khamenya at mail dot ru