From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [VM] Tail recursion and multiple values Date: Mon, 02 Mar 2009 19:03:28 +0100 Message-ID: References: <871vtiiqma.fsf@gnu.org> <8763iuhb7k.fsf@gnu.org> <87y6vox0s9.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1236017123 26097 80.91.229.12 (2 Mar 2009 18:05:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2009 18:05:23 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 02 19:06:37 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LeCVo-00024U-D0 for guile-devel@m.gmane.org; Mon, 02 Mar 2009 19:05:33 +0100 Original-Received: from localhost ([127.0.0.1]:45334 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeCUS-0003NR-PE for guile-devel@m.gmane.org; Mon, 02 Mar 2009 13:03:44 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeCUM-0003Mu-35 for guile-devel@gnu.org; Mon, 02 Mar 2009 13:03:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeCUJ-0003M4-Ms for guile-devel@gnu.org; Mon, 02 Mar 2009 13:03:37 -0500 Original-Received: from [199.232.76.173] (port=35715 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeCUJ-0003M1-HQ for guile-devel@gnu.org; Mon, 02 Mar 2009 13:03:35 -0500 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:65073 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LeCUC-0000o1-QO; Mon, 02 Mar 2009 13:03:29 -0500 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 063A82678; Mon, 2 Mar 2009 13:03:25 -0500 (EST) Original-Received: from unquote (unknown [81.39.160.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 579372676; Mon, 2 Mar 2009 13:03:23 -0500 (EST) In-Reply-To: <87y6vox0s9.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 02 Mar 2009 00:48:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 6CB541B6-0754-11DE-8C8F-CBE7E3B37BAC-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8204 Archived-At: Heya, On Mon 02 Mar 2009 00:48, ludo@gnu.org (Ludovic Court=C3=A8s) writes: >> 1) It is expected that you don't have tail recursion between >> interpreted and VM code. >> >> 2) This particular problem manifests itself in that call-with-values >> is VM code (when r5rs.scm is compiled). > > (The latter is what I meant to say in my message.) > > As for (1), I'm unsure. The issue is that as long as running code with > the interpreter is the default, people may hit this kind of problem, > which is, well, problematic. Now, I have no idea how this could be > solved without resorting to dirty hacks such as the one you suggested. Yeah. It is certainly a counterintuitive situation. The compiler recognizes both call-with-values and @call-with-values, so we could just not compile call-with-values; less nasty, but still nasty, and penalizes the vm in the (apply call-with-values ...) case. > As a side note, I think it makes sense to keep the interpreter as the > default when evaluating `.scm' files Sure, for now -- or we could do what python does, and automatically create .go files as needed (and if possible). Then it would certainly pay off over time, and the compilation time would probably be a wash because in that case the .scm probably isn't even in the disk cache. > the program is short-lived This would be the normal case > if the compiler performs smart optimizations, Hahaahaha! More seriously, I think that the bar for including optimizations in the normal compilation path will be if they actually speed up the compiler as well (since the compiler is self-compiled). Cheers, Andy --=20 http://wingolog.org/