From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 13:18:28 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009df8cc059c189718" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="30190"; 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 13:19: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 1irL9v-0007Ot-Qg for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 13:18:59 +0100 Original-Received: from localhost ([::1]:38350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irL9u-0006ZR-Lp for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 07:18:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34961) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irL9g-0006Xv-R7 for guile-devel@gnu.org; Tue, 14 Jan 2020 07:18:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irL9d-00080J-Bq for guile-devel@gnu.org; Tue, 14 Jan 2020 07:18:44 -0500 Original-Received: from mail-vk1-f169.google.com ([209.85.221.169]:41616) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irL9d-00080F-74 for guile-devel@gnu.org; Tue, 14 Jan 2020 07:18:41 -0500 Original-Received: by mail-vk1-f169.google.com with SMTP id p191so3531167vkf.8 for ; Tue, 14 Jan 2020 04:18:40 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc; bh=FzYRpCvn6yLGBVRQhiHcb+CnfwCF6Hsl2Dsq6L8DU6s=; b=dEdpW+jhPUlDqZz6kO1weNH9JlD9AIgOKTW7WF+QQ8wSN/784wP67xd4xWcR7t51Pm OqCrNbwxUPdcLiW0LP1b3IYofg5OvqG/UkvLD2JaXpIFNA72WM05U4x4pRUpFUJZrAeQ hswEFrj4JWiqIBA84+Yj4U5YisunDiYLEw1ytQrkxX3C0yT8y4+FcM/5qWBlMKWRUtgb cFnmEX5fAL34wkjrPlZ0N5D5hENuMSUT79bKtV3kT5MJQeXCWZape8RjhkOVLNkoLJsb iOls/cbuuMQQ7t13DZ8gYg6ceYUTUc2KiU9lUCa40ECDN/ZRCKQnyhicIdRKFEr+GHx9 rLpg== X-Gm-Message-State: APjAAAWbHQpvlCu0rUSgyscvPh0hTq4RaWvlL3MLmTy1mqk5tB1MUY2M sD5JiE0K1OnSUk1e2ocnsCnJTaLHjwhjWSNLik4= X-Google-Smtp-Source: APXvYqwGOzYVt12V7SjobOAmpu9m9AcT1YnCI4c8zO45j8K8zQHTd9vIogYw1fpHPsjy+KP3fPIbbj4a/9HGt9ryzqM= X-Received: by 2002:a1f:db81:: with SMTP id s123mr10617387vkg.45.1579004320411; Tue, 14 Jan 2020 04:18:40 -0800 (PST) In-Reply-To: <87eew2i8z3.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.221.169 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:20264 Archived-At: --0000000000009df8cc059c189718 Content-Type: text/plain; charset="UTF-8" Dear Andy, I probably don't have a clue about what you are talking about (or at least hope so), but this---the "eq change"---sounds scary to me. One of the *strengths* of Scheme is that procedures are first class citizens. As wonderfully show-cased in e.g. SICP this can be used to obtain expressive and concise programs, where procedures can occur many times as values outside operator position. I would certainly *not* want to trade in an important optimization step in those cases to obtain intuitive procedure equality. The risk is then that you would tend to avoid passing around procedures as values. Have I misunderstood something or do I have a point here? Best regards, Mikael Den tis 14 jan. 2020 12:18Andy Wingo skrev: > On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe > writes: > > > In current guile (eq? f f) = #f for a procedure f. Try: > > Note that procedure equality is explicitly unspecified by R6RS. Guile's > declarative modules optimization took advantage of this to eta-expand > references to declaratively-bound top-level lambda expressions. This > unlocks the "well-known" closure optimizations: closure elision, > contification, and so on. > > However, the intention with the eta expansion was really to prevent the > > (module-add! mod 'foo foo) > > from making the procedure not-well-known. If that's the only reference > to `foo' outside the operator position, procedure identity for `foo' is > kept, because it's only accessed outside the module. But then I > realized thanks to your mail (and the three or four times that people > stumbled against this beforehand) that we can preserve the optimizations > and peoples' intuitions about procedure equality if we restrict > eta-expansion to those procedures that are only referenced by value in > at most a single position. > > It would be best to implement the eta-expansion after peval; doing it > where we do leaves some optimization opportunities on the table. But I > have implemented this change in git and it should fix this issue. > > Comparative benchmark results: > > > https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-microbenchmarks.png > > Regards, > > Andy > > --0000000000009df8cc059c189718 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Andy,

I probably don't have a clue about what you are talking about (or a= t least hope so), but this---the "eq change"---sounds scary to me= .

One of the *strengths*= of Scheme is that procedures are first class citizens. As wonderfully show= -cased in e.g. SICP this can be used to obtain expressive and concise progr= ams, where procedures can occur many times as values outside operator posit= ion.

I would certainly *= not* want to trade in an important optimization step in those cases to obta= in intuitive procedure equality. The risk is then that you would tend to av= oid passing around procedures as values.

<= div dir=3D"auto">Have I misunderstood something or do I have a point here?<= /div>

Best regards,
Mikael

Den tis 14 jan. 2020 12:18Andy Wingo <wingo@pobox.com> skrev:
On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <= stefan.itampe@gmail.com> writes:

> In current guile (eq? f f) =3D #f for a procedure f. Try:

Note that procedure equality is explicitly unspecified by R6RS.=C2=A0 Guile= 's
declarative modules optimization took advantage of this to eta-expand
references to declaratively-bound top-level lambda expressions.=C2=A0 This<= br> unlocks the "well-known" closure optimizations: closure elision,<= br> contification, and so on.

However, the intention with the eta expansion was really to prevent the

=C2=A0 (module-add! mod 'foo foo)

from making the procedure not-well-known.=C2=A0 If that's the only refe= rence
to `foo' outside the operator position, procedure identity for `foo'= ; is
kept, because it's only accessed outside the module.=C2=A0 But then I realized thanks to your mail (and the three or four times that people
stumbled against this beforehand) that we can preserve the optimizations and peoples' intuitions about procedure equality if we restrict
eta-expansion to those procedures that are only referenced by value in
at most a single position.

It would be best to implement the eta-expansion after peval; doing it
where we do leaves some optimization opportunities on the table.=C2=A0 But = I
have implemented this change in git and it should fix this issue.

Comparative benchmark results:

=C2=A0 https://wingolog.org/pub/guile-2.9.7-vs-guile-2.9.9-with-eq-change-micr= obenchmarks.png

Regards,

Andy

--0000000000009df8cc059c189718--