From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Vladimir Zhbanov Newsgroups: gmane.lisp.guile.user Subject: Re: Weird Guile Scheme Behaviour Date: Fri, 13 Sep 2019 20:22:59 +0300 Message-ID: <20190913172259.GA6220@newvzh.lokolhoz> References: <87pnk4v8et.fsf@bulbul> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171423"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Sep 13 19:23:27 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i8pI7-000iSr-Gt for guile-user@m.gmane.org; Fri, 13 Sep 2019 19:23:27 +0200 Original-Received: from localhost ([::1]:46392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8pI5-00019U-Uv for guile-user@m.gmane.org; Fri, 13 Sep 2019 13:23:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42480) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8pHm-000198-Az for guile-user@gnu.org; Fri, 13 Sep 2019 13:23:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i8pHl-0001Oz-10 for guile-user@gnu.org; Fri, 13 Sep 2019 13:23:06 -0400 Original-Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]:36468) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i8pHk-0001Ni-NQ for guile-user@gnu.org; Fri, 13 Sep 2019 13:23:04 -0400 Original-Received: by mail-lj1-x244.google.com with SMTP id v24so234688ljj.3 for ; Fri, 13 Sep 2019 10:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=mc7xNx0jplTJDoQX36LmLEORWA3/73OekaGVh+tdT40=; b=XWo0hcb1iBZ9q5DQp2dp5Fnn8nHMy/N0V++7uKod9R5NEfxgsGrdHwPouDUhWmvehJ WC/cuvv+6x1rYleWNO2zoHXByvtZBL3Wj1moBhFw8VwyCFbwEC1y9AMRfs2mDcJgizI+ WpbObZKhRTxTW/H9p8eL9acnNF7TFUVvCb6TRzBQMc6XEOYHxK+XHmvpCOlmGeY0ZZKY enlgOsSKcY8Qxz1HV93j4ZJQfUFhuJpfEeF9/MOflbRdtCdHq0cfrl8Njf16kiGMGwJc FGO0LbWNRSMtVuotcTnZfwyGJ1V61ak40lDT6r9b4MUbS3hjU8Liji2gkLnKcQ8MrwQA 1p1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=mc7xNx0jplTJDoQX36LmLEORWA3/73OekaGVh+tdT40=; b=S6RTfR7MvxgMv+JPDY0YkQZzrUsg5wc08+xJH+2IXauxNJn4eInjt8lVtkd+HzKeLR Rq1iQ4SWPAwEtz5Ez0DnC7djFxffuTMizuR5uLEspaOxV+m7TFhj5HGER+hS1+s2S2rY h8IWYeDuoDjWOqX5DhTaa8sjoU0M82lDIM5aNd9IWwtMgE+kLktv0F+NFsIq1k5iV6dg D/CL2iGRrCnfGE6ekLPKR2JOjnoDLk8Nac0kT21bgsi7SG72hSjCbkEJhtIDstZKT9wJ pjXSmPi23fo1SyDG+Tpd7VWb5wxaykboe8NbqY2sgnJ1WvJ5t6AXE3Ufdtn/fBYtV59H 7SCw== X-Gm-Message-State: APjAAAUg5Bjnu4D2eDExuF+n9nsyFCQOXeLpCAxGNUomltVOvyxXUKuH YHAB3LByRuelIeTfMe4A3xWhW8nd X-Google-Smtp-Source: APXvYqyeWSL5nXiosMJqwkEW9tPIvKqwCOUrG9hmsd4xPPYO484ExPvPLUmOQZNyq0myqXP4rJ4fJQ== X-Received: by 2002:a2e:6e1a:: with SMTP id j26mr10420982ljc.172.1568395382373; Fri, 13 Sep 2019 10:23:02 -0700 (PDT) Original-Received: from newvzh.lokolhoz ([95.179.127.163]) by smtp.gmail.com with ESMTPSA id j84sm6620375ljb.91.2019.09.13.10.23.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Sep 2019 10:23:01 -0700 (PDT) Original-Received: from vovka by newvzh.lokolhoz with local (Exim 4.92) (envelope-from ) id 1i8pHg-0002gJ-6y for guile-user@gnu.org; Fri, 13 Sep 2019 20:23:00 +0300 Mail-Followup-To: guile-user@gnu.org Content-Disposition: inline In-Reply-To: <87pnk4v8et.fsf@bulbul> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::244 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15726 Archived-At: Philip, On Fri, Sep 13, 2019 at 11:43:06AM +0200, Philip K. wrote: > > Hi, > > I was reading a thread on an imageboard[0] the other day, then I came > across a most peculiar "bug", if it even is one. Since the original > example was a bit dense (it tried to solve a problem someone else had > posted, that's not relevant here), I tried to construct a minimal > working example to discuss here. > > Compare > > (define (reverse-iota-1 max) > (let ((numbers '(start))) > (let loop ((val 0)) > (append! numbers > (if (< max val) > '() > (begin > (loop (1+ val)) > (list val))))) > numbers)) > > and > > (define (reverse-iota-2 max) > (let ((numbers '(start))) > (let loop ((val 0)) > (append! numbers > (if (< max val) > '() > (begin > (loop (1+ val)) > (list val))))) > (cdr numbers))) > > (I know, the style is horrible, but that's not the point. Also, both > have an internal state, so you have to re-eval the function every time > before starting the function itself.) > > The only difference is in the last line. The first function returns the > entire list (with the start symbol), and the second tries to chop it > off. > > But what happens is that (reverse-iota-1 4) evals to '(start 3 2 1 0) > while (reverse-iota-2 4) just returns '()! > > This seems weird, since my intuition, and that of the poster above, was > that all that should change in reverse-iota-2 is that the "start" symbol > should fall away. > > It's obvious that this has something to do with the destructive > "append!", but I'm not quite sure what leads to this unexpected result. > Is it maybe a optimisation error? Any opinions? Well, if i understand the issue correctly, there are two issues :-) 1) The quotation from the Guile manual: ‘append’ doesn’t modify the given lists, but the return may share structure with the final OBJ. ‘append!’ is permitted, but not required, to modify the given lists to form its return. 2) 'let' itself should return the last evaluated expression (right?). The external 'let' does just so, and the internal 'let' is irrelevant (apart from the issue with permission to 'append!', shown above, to modify the value of its arguments) . So, if you would use just 'append' instead of 'append!', you would get just the value of 'numbers' (just '(start)) in the first case, and the value of its 'cdr' in the second case (obviously, '() :-)). However, since 'append!' is used instead, it is unpredictable for me (the behaviour of 'append!' is not standardized), if it will change the value of 'numbers' itself, so there are two cases you've got. Well, dunno, which conditions force the Guile optimizer to choose one of the strategies. Seems, i would prefer internal 'let's in both cases are thrown out. -- Vladimir (λ)επτόν EDA — https://github.com/lepton-eda