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 17:36:22 +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="000000000000dbbe30059c1c3152" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="117570"; 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 17:36:56 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 1irPBW-000UCd-OT for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 17:36:54 +0100 Original-Received: from localhost ([::1]:43242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPBV-0008Mw-Ki for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 11:36:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59417) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPBE-0008MA-Dv for guile-devel@gnu.org; Tue, 14 Jan 2020 11:36:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irPBD-0006ny-7M for guile-devel@gnu.org; Tue, 14 Jan 2020 11:36:36 -0500 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:35542) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irPBC-0006lX-Uu for guile-devel@gnu.org; Tue, 14 Jan 2020 11:36:35 -0500 Original-Received: by mail-wm1-x332.google.com with SMTP id p17so14514208wmb.0 for ; Tue, 14 Jan 2020 08:36:34 -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=cycQlsFPDP4t5OZe6v3le/wxjSLg2Ao2Vhuf/u6I0FM=; b=DIIgtNSVKk+3U1QFAU7TU9l1nC6e/h2HthJ1Bl0eOFL0Ny1edkSICTXSEtcU7HcLO/ jXDdgvDykWsngiKT+N/tXxe/jddyK3N8AHpoShq3bc98R558CL35oKscC5biuQbv4GZE RiFOxLzveYrdn0uJGqHA8hiKR3BCeoyYKxkwbWLUJNvNxFYRhUy/gJ5SxsQMBqSq7ic/ wvVlTtNEzrC2uiMVuiEswJSHtzRRJNich56a24eyvDAHJDMzstvBVUur+KQHU824akaz QyfgxSe7ZAPQaRoVxSLFlqrwRZJejdVc4q0f7tYblkfY1QIq9ZPhuLqbZRZD4ZLzW6UV b70w== 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=cycQlsFPDP4t5OZe6v3le/wxjSLg2Ao2Vhuf/u6I0FM=; b=TFzFBrwz3IQcFqOCu8VBqnJxf51/71iZcNoYE7G6Tpu/w2wDpG0+kdUjhybuii4RgY qZx6LN5HS9Xer2KK2ku+yG5VVG5cV+Ts/H0FswWPkgOsa+DFFZBTjzUbyjrgCHCrX+4K JCRN3Wqpe/PPM+UlHQS/HcilwP/PB42XnZDT8RT1LgPD6WnMvpiWPHvX58KG3k10Hy/I jywrKLIaPUPT5xqvRlgN3PHq586vq4+meW+nru1eadHlgp6Bn1+rjQzZYddJPn7BO6+m 3V3txGXrrBoafeErfip4/5j2AZ6VM9BlpYd3nZvfTAy0INyeadkSE7839yC2QmfUgb5g gPTg== X-Gm-Message-State: APjAAAV14sSVZmMeNFK1eB8vpDyQ5JDtehGQEbHVQ2qxooKU+thwJcfs WfYGbBdtQ8OLGGCthOhI1Z/Q2AKUQRRkob89gtI= X-Google-Smtp-Source: APXvYqz4HwO4uWUWMRo3UqLOkvcB2gGmMzkVJ7w9lusL+8LxyEG34/dvzh+aCEuS+V/iR4jktrGRwuFv7SAmLfPIwS0= X-Received: by 2002:a7b:c1d8:: with SMTP id a24mr28294474wmj.130.1579019793053; Tue, 14 Jan 2020 08:36:33 -0800 (PST) In-Reply-To: <87imleggjt.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::332 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:20271 Archived-At: --000000000000dbbe30059c1c3152 Content-Type: text/plain; charset="UTF-8" 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 > 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 > --000000000000dbbe30059c1c3152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1. I don't understand why you decrement the count in o= perator position
2. I don't see that you increase the count when a = procedure is returned from a lambda

Example
<= div>(define (f a) a)
(define (g)
=C2=A0 =C2=A0 (hash-se= t! H f 1) ; (*)
=C2=A0 =C2=A0 (f 1)) ;(**)
(define (h)<= /div>
=C2=A0 =C2=A0(pk (hash-ref H f))) ; (*)

<= div>(g)
(h)

=3D> '(#f) as count i= n your patch is counted up twice=C2=A0(*)=C2=A0and down ones (**) in total = count =3D 1 so you will not maintain the identity of f and you will get a b= ad printout

Then we also have this example
(define (f a) a)
(define (u) f)
(define (g) (hash-se= t! H (u) 1))
(define (h) (pk (hash-ref H f)))

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

/Stefan





=




=




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







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

> 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
--000000000000dbbe30059c1c3152--