Re: Compilers for Guile (related to roadmap and goals)

[Christopher Cramer <crayc@pyro.net>]

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 <crayc@pyro.net> <http://www.pyro.net/~crayc/>
Quoi que vous fassiez, écrasez l'infâme, et aimez qui vous aime.
	-- Voltaire

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel