This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RTL/tree (from gcc) and Scheme


Valery A.Khamenya wrote:

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"?

Loosely, anything that involves lexical scoping is "non-trivial". Function application, variable references, literals, conditionals, and begin forms are trivial. Lambda and let forms are non-trivial.

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. :-(

There was a break-in at the GNU site, and they are verifying the various files. I don't know when they'll be back or whether I can do something to improve this.

If you can use CVS, I suggest getting Kawa from CVS - which is
using a different server.

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?

I don't see having trees available "at run-time" will help here. There is nothing in principle that prevents people from writing other langauge implementations - it just isn't as easy as one would like, especially since the API isn't a frozen stable API.

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

You're not asking for "RTL/trees at run-time" but "a library interface for invoking Gcc from an application". That is very difficult, for both technical and licensing reasons.

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.

That helped explain what your're looking for. However, it's not going to be easy ...

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

No, RLT is no-where near Scheme. You're confused by the Lisp-like syntax used when printing out RTL. However, it is way too low-level to be useful for Scheme. A Scheme GCC compiler would generate trees, not RTL. Or do you mean using Scheme to manipulate RLT, perhaps writing new implementations in Scheme, etc? There doesn't seem to be any advantage in that: Processing RTL is always plenty time-consuming, and using Scheme would just make things slower without much benefit.

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?)

No. The original motivation came from a contract at Cygnus.


BTW, are you still along working on kawa?

Yes - even occasionally getting paid for it. I'm working hard on implementing XQuery (http://www.w3.org/XML/Query) using the Kawa compiler framework, but also working on improving the Scheme implementation.

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

I assumed from your domain name you were in Russia. -- --Per Bothner per@bothner.com http://per.bothner.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]