From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile Assembler Date: Fri, 04 Sep 2015 12:58:13 -0400 Message-ID: <87r3me5dga.fsf@netris.org> References: <1435040921.1695.4.camel@Renee-desktop.suse> <20150623091251.GA19575@tuxteam.de> <1435051196.1695.13.camel@Renee-desktop.suse> <20150623092715.GD19575@tuxteam.de> <1435051842.1695.15.camel@Renee-desktop.suse> <20150623094526.GA20821@tuxteam.de> <20150624083420.GA25584@tuxteam.de> <878u8n0zs6.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441385954 2841 80.91.229.3 (4 Sep 2015 16:59:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2015 16:59:14 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Panicz Maciej Godek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 04 18:59:13 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZXuKV-0005vV-7t for guile-devel@m.gmane.org; Fri, 04 Sep 2015 18:59:11 +0200 Original-Received: from localhost ([::1]:33560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXuKV-0004P4-01 for guile-devel@m.gmane.org; Fri, 04 Sep 2015 12:59:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXuKO-0004IX-UZ for guile-devel@gnu.org; Fri, 04 Sep 2015 12:59:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXuKL-0002tf-On for guile-devel@gnu.org; Fri, 04 Sep 2015 12:59:04 -0400 Original-Received: from world.peace.net ([50.252.239.5]:49368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXuKL-0002tS-MO for guile-devel@gnu.org; Fri, 04 Sep 2015 12:59:01 -0400 Original-Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZXuKF-0001Zt-8n; Fri, 04 Sep 2015 12:58:55 -0400 In-Reply-To: (Panicz Maciej Godek's message of "Fri, 4 Sep 2015 11:31:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17821 Archived-At: Panicz Maciej Godek writes: > Actually, the code is written in such way that "loop" is actually a > macro such that > > (loop (values 4 (list 5 6))) > > would expand to > > (loop* (values->list (values 4 (list 5 6)))) > > where loop* takes lists as inputs and (values->list call) is a syntax > defined as (call-with-values (lambda () call) list), so I think it is > a proper Scheme code which does not rely on any undefined behaviors. Ah, okay. You're right, this is fine, sorry for the noise. > It has some drawbacks -- among others, that loop is no longer first > class (although it could be made obtainable easily) and the resulting > code is rather inefficient, but it ought to behave properly. Indeed, it's not good for looping constructs to do heap allocation. If the loop would not otherwise require allocation, then using such a looping construct will result in a dramatic slowdown. Mark