From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Christopher Cramer Newsgroups: gmane.lisp.guile.devel Subject: Re: Compilers for Guile (related to roadmap and goals) Date: Tue, 23 Apr 2002 17:03:38 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <20020423170338.A10827@kiwi.pyrotechnics.com> References: <3CC4FE4E.1B343860@staff.ttu.ee> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1019599621 2571 127.0.0.1 (23 Apr 2002 22:07:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2002 22:07:01 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 1708R9-0000fE-00 for ; Wed, 24 Apr 2002 00:07:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 1708NV-0002YO-00; Tue, 23 Apr 2002 18:03:13 -0400 Original-Received: from pyro.net ([207.7.10.2] helo=kiwi.pyro.net) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 1708M8-0002Sj-00 for ; Tue, 23 Apr 2002 18:01:48 -0400 Original-Received: (qmail 17237 invoked by uid 8610); 23 Apr 2002 22:03:38 -0000 Original-To: Tanel Tammet Mail-Followup-To: Tanel Tammet , guile-devel@gnu.org Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC4FE4E.1B343860@staff.ttu.ee>; from tammet@staff.ttu.ee on Tue, Apr 23, 2002 at 09:25:18AM +0300 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:478 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:478 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 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