From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 18:56:32 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> <87pnfmglbo.fsf@pobox.com> <87imleggjt.fsf@pobox.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000097d519059c1d50bf" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="262521"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 18:57:01 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.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 1irQR1-0015nz-FR for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 18:56:59 +0100 Original-Received: from localhost ([::1]:44260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irQQz-0000J0-Nf for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 12:56:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47184) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irQQo-0000Im-71 for guile-devel@gnu.org; Tue, 14 Jan 2020 12:56:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irQQn-0002s3-1E for guile-devel@gnu.org; Tue, 14 Jan 2020 12:56:46 -0500 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:34231) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irQQm-0002ri-RH for guile-devel@gnu.org; Tue, 14 Jan 2020 12:56:44 -0500 Original-Received: by mail-wm1-x32a.google.com with SMTP id w5so2853661wmi.1 for ; Tue, 14 Jan 2020 09:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G4S1gOpH3Xyt5HG/FrbMGhOovp0e5WF98hGCixJYsfM=; b=WdpnHLC5f/jQzAEtzc/oaYgggPwmXirJf9fuL4dTNVJPMfeQDUlHHQoj/U7KJMfUKK pculEWdcdSFO1SAB7tLDYnv9RMaMSAMSP+3ZCJYQkw/AoH/VNEqBlouNvfay9WtAvLqT NFSkvoVcGQ9VgIpbpp3bR757HUb8Q14rZ8r30nhL2vW3QHQCtz8DHLExB01NX1nHZklI sWApMPLy8AN7FvICM8OtwtOXQqU+tSQU/n/6J9T0zuAsMm4tgMnn3abNHFE86UpmmpCc 50CO2ZUyODohxFOp14neHkLhZN58pr43lLMOhG640DSGOQe9ivCIWKGNeXTz+LTL0aE6 dk2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G4S1gOpH3Xyt5HG/FrbMGhOovp0e5WF98hGCixJYsfM=; b=VYbEF/EW3kTOtLjy3CAftFgEG2RvLiVidBH7cT3GFHPD0x6FQq5PBGZF/+eWXOxYx1 0Qtlkg2NMIRdLn/gxADWXgP3o9bsGf4U1R6I4IhH3yagEx1C6Czhf1FAkDoXajFnmrOt PmCDnN4t0zPwW9aIG7+QUrEUoMp56ZwzPcneq/PoEW3rbrDTYgpi8AJq5gE87BVTFOgB xrS5bzVjgz/O+mfOetffI3T0qQYgdTptC2FBlWBbKQkyzlN2oO8DIp5up8Uo8dNNNJhD brp/HOeVt+ySHwbLsS3yqq5PtskqsBVN8K8LhzG6m4gAzZWClrnzROwThcGzkImSuJD1 tOlA== X-Gm-Message-State: APjAAAXLuRFA6pA9ouyVJUZ/qK7tAlcY2mJFdkSjl3nUyVL99t6fBIwS 9P9ESUOK2/2mnTJedrr+fi7jD8kTvlh8ev8E85w= X-Google-Smtp-Source: APXvYqyrp/d6FR8P4h1njmcTs0ws3lj0okjCuhEV05JeqNRhDNpCDR+fzFLXDWdMPP4kZYn7QmUGEGxkERA8NqCwND8= X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr12867297wmo.13.1579024603664; Tue, 14 Jan 2020 09:56:43 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32a X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20276 Archived-At: --00000000000097d519059c1d50bf Content-Type: text/plain; charset="UTF-8" I'll apply your patch and see if it works. After reading it more carefully I think I understand your decrement count. Nice code! On Tue, Jan 14, 2020 at 5:36 PM Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > 1. I don't understand why you decrement the count in operator position > 2. I don't see that you increase the count when a procedure is returned > from a lambda > > Example > (define (f a) a) > (define (g) > (hash-set! H f 1) ; (*) > (f 1)) ;(**) > (define (h) > (pk (hash-ref H f))) ; (*) > > (g) > (h) > > => '(#f) as count in your patch is counted up twice (*) and down ones (**) > in total count = 1 so you will not maintain the identity of f and you will > get a bad printout > > Then we also have this example > (define (f a) a) > (define (u) f) > (define (g) (hash-set! H (u) 1)) > (define (h) (pk (hash-ref H f))) > > (g) > (h) > This will again print (#f) as the count will be 1. > > /Stefan > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 14, 2020 at 5:16 PM Andy Wingo wrote: > >> On Tue 14 Jan 2020 15:47, Stefan Israelsson Tampe < >> stefan.itampe@gmail.com> writes: >> >> > Yes, your patch is indicating when you should use the same identity >> > e.g. all uses of procedures in a higher order position such as an >> > argument or a return value. But I looked at your patch, which looks >> > good but I saw that for operator position you decrease the count. Why? >> > Also you are free to use one version in argument / return position and >> > another one in operator position the only limit is to use the same >> > identity for on operator position. Finally don't you need to count >> > usage of returning a variable as well? >> >> Not sure what the bug is. Do you have a test case that shows the >> behavior that you think is not good? >> >> Andy >> > --00000000000097d519059c1d50bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll apply your patch and see if it works. After readi= ng it more carefully I think I understand your decrement count. Nice code!<= /div>
O= n Tue, Jan 14, 2020 at 5:36 PM Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
=
1. I don= 't understand why you decrement the count in operator position
2. I= don't see that you increase the count when a procedure is returned fro= m a lambda

Example
(define (f a) a)
(define (g)
=C2=A0 =C2=A0 (hash-set! H f 1) ; (*)
=C2=A0 =C2=A0 (f 1)) ;(**)
(define (h)
=C2=A0 =C2=A0(p= k (hash-ref H f))) ; (*)

(g)
(h)

=3D> '(#f) as count in your patch is counted u= p twice=C2=A0(*)=C2=A0and down ones (**) in total count =3D 1 so you will n= ot maintain the identity of f and you will get a bad printout
Then we also have this example
(define (f a) a)
=
(define (u) f)
(define (g) (hash-set! H (u) 1))
(d= efine (h) (pk (hash-ref H f)))

(g)
(h)
This will again print (#f) as the count will be 1.

<= /div>
/Stefan


=





=







=C2=A0 =C2=A0=C2=A0








On Tue, Jan 14, 2020 at 5:16 PM Andy Wingo <wingo@pobox.com> = wrote:
On Tue 14= Jan 2020 15:47, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Yes, your patch is indicating when you should use the same identity > e.g. all uses of procedures in a higher order position such as an
> argument or a return value. But I looked at your patch, which looks > good but I saw that for operator position you decrease the count. Why?=
> Also you are free to use one version in argument / return position and=
> another one in operator position the only limit is to use the same
> identity for on operator position. Finally don't you need to count=
> usage of returning a variable as well?

Not sure what the bug is.=C2=A0 Do you have a test case that shows the
behavior that you think is not good?

Andy
--00000000000097d519059c1d50bf--