[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilers for Guile (related to roadmap and goals)
From: |
Christopher Cramer |
Subject: |
Re: Compilers for Guile (related to roadmap and goals) |
Date: |
Tue, 23 Apr 2002 17:03:38 -0500 |
User-agent: |
Mutt/1.2.5i |
On Tue, Apr 23, 2002 at 09:25:18AM +0300, Tanel Tammet wrote:
> 2) The last distro compilation claimed smth about a duplicate
> definition (cannot remember exactly): one of the internet-oriented
> functions ins Guile .c clashed with a standard one in the Linux
> (gcc?) library. I could fix it in source, though.
Anyone who follows bug-guile is not only familiar with, but probably
sick of, this problem. It has been puzzling to me why this wasn't fixed
a long time ago. There seems to be some sort of bureaucratic problem
with releasing another 1.4.x with just a fix for this problem.
> Obviously, many Guile developers do not think
> speed is important (otherwise Guile would be at least
> as fast as SCM and would have a compiler).
In their defense, sometimes other things take priority over speed.
I agree with the rest of your argument though; speed is very important.
> - It would probably be trivial to make Hobbit understand
> guile primitives. For example, Aubrey hacked Hobbit
> to support the last versions of SCM. I can do that too :)
One of the difficulties, from what I've seen, is that most of the module
system isn't made up of primitives. It leads to sort of a chicken and
egg problem: how do you compile the module system, when the compiler
depends on the module system? But I may be misunderstanding the problem.
> There are three kinds of code where Hobbit loses in a major
> way to Stalin etc:
>
> - code using call/cc in speed-critical parts. The slowness
> of this stems from the way scm (and guile) are interpreted
> (using stack), NOT hobbit. You can make such code compile
> nicely only with a completely different (non-stack) approach,
> and many byte-code compilers do this (hence being fast
> on call/cc).
I think the consensus is that call/cc just isn't going to be fast if
you want to interface with C. I suppose if you can detect upward-only
uses of call/cc, those uses can be done with setjmp.
> - code relying on fast (proper) implementation of tailrecursion
> for mutually tail recursive functions. Hobbit (and Bigloo, for
> example) only recognise tail recursion inside a function, not
> mutual tail tail recursion between different functions.
This is pretty much impossible to solve without help from the C compiler.
But, hey, we can change gcc, so anything is possible.
> And now, the final question after the long story:
> is anybody from the Guile community right now hacking
> Hobbit or some other scheme-to-c compiler for Guile?
I have tried to get Hobbit working again, but I don't have any experience
with compiler development, and I didn't get very far. Mostly what I got
was an urge to rewrite the module system.
--
Christopher Cramer <address@hidden> <http://www.pyro.net/~crayc/>
Quoi que vous fassiez, écrasez l'infâme, et aimez qui vous aime.
-- Voltaire