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 14:25:09 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000555e1059c1986a2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29732"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Andy Wingo , guile-devel To: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 14:26:04 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 1irMCk-0007BL-IY for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 14:25:58 +0100 Original-Received: from localhost ([::1]:39524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irMCj-0000aR-75 for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 08:25:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47082) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irMCB-0000YI-7Z for guile-devel@gnu.org; Tue, 14 Jan 2020 08:25:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irMC9-0001wN-JJ for guile-devel@gnu.org; Tue, 14 Jan 2020 08:25:23 -0500 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:40759) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irMC9-0001wG-Bz for guile-devel@gnu.org; Tue, 14 Jan 2020 08:25:21 -0500 Original-Received: by mail-wm1-x333.google.com with SMTP id t14so13710449wmi.5 for ; Tue, 14 Jan 2020 05:25:21 -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=QAXPiiwPwBzWGDlDYRysypEt5+AyqSz3AG9c7aUszHg=; b=OfIwhKHTeCv0KVHdx59YyFtFEReXuBdYWI84ZHPUo6vwhH6QPkLApN8ivUUiIKoI0U 5AetWkBdIBfZyxRyZDpJkP9S0to+uAOQiu+IS/9mIYLVgPNBz0CJBi8EYzje1mnNBtXj vUC8LSTA2gPMZvyCppBGjx1FSX7yo8TE1z0GVH2G7xXtppzdyxzQpdlwxykLOEVceBUG yYcEBZynDuW5NRiai90nN3JCLOiEWIyowBCYBth3cKBFog3qBsy7U7fOAzirbfqreIJP fVDmA55c9IwXV+RP/L7mDhXfMxPTyzFQB/vtcVXBptLmALrA6b1mbBxTOQ3vQGUB8Gef m6tQ== 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=QAXPiiwPwBzWGDlDYRysypEt5+AyqSz3AG9c7aUszHg=; b=bS8FHZMLdpOeY805/0QFD/IacLDjLWXTOe0tn2IS5pXXLsfBPVQVthi3YUMrXo7Qt5 m3pH5m2Swt+tIi4om8DNZ96EvTkz+VeZshRdbCM4Ezyp1QfIAsYjniIwNhP8Lz2OpQSz ohEURfupZyKXHdh6Uedao/mkL6QmCLuIiNTFGsA5jKLLczSUuYDaSCCgHEgPBDqs5PjK SzWymh1w3vPjVd3NA9GrWT+/luNUcHlkJmk2kNaz1vL8f3ziWTB5rGpepcdYp3KIa03O q1hISw65ftsBjC6QAXxSz47AHf8nIYiI/qDOTSahOavonIIptS0DLbBFcb2getanZLYm +iWg== X-Gm-Message-State: APjAAAXBQt28Xyw6/lLVCCC94nxGNFTU5drDqZWRzWhZcf6FdEsPWK4k g8uAZ4VQYesfVsgfJ5G29CZKEcG64jzY2HunqLs= X-Google-Smtp-Source: APXvYqyG8uB/LD1an8uNKnFKPdofuyQjywOFy48e4cuwK5YP4BfjtQi+Gf6KAhUR6b8WhYITadoXePKHBGC7WV0M9Ls= X-Received: by 2002:a1c:7d93:: with SMTP id y141mr27897631wmc.111.1579008320164; Tue, 14 Jan 2020 05:25:20 -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::333 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:20265 Archived-At: --0000000000000555e1059c1986a2 Content-Type: text/plain; charset="UTF-8" I agree about the scary part as it e.g. would make it impossible to use procedures in hashmaps (where my trouble stems from) in any sane way, I know how to fix my code but there will be a lot of anger on the mailinglist and irc to teach how to avoid the problems. Fortunately probably the next release will have fixes to this and we will regain the identity features. Also it is scary that scheme spec allows compilers to abuse the usage of procedure identities. On Tue, Jan 14, 2020 at 1:18 PM Mikael Djurfeldt wrote: > 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 < >> stefan.itampe@gmail.com> 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 >> >> --0000000000000555e1059c1986a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree about the scary part as it e.g. would make it impo= ssible to use procedures in hashmaps (where my trouble stems from) in any s= ane way, I know how to fix=C2=A0
my code but there will be a lot of ang= er on the mailinglist and irc to teach how to avoid the problems.

Fortunately=C2=A0probably the next=C2=A0release will have f= ixes to this and we will regain the identity features.

=
Also it is scary that scheme spec allows compilers to abuse the usage = of procedure identities.





On Tue, Jan 14, 2020 at 1:18 PM Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
=
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. SIC= P this can be used to obtain expressive and concise programs, where procedu= res 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 proce= dure equality. The risk is then that you would tend to avoid passing around= procedures as values.

H= ave I misunderstood something or do I have a point here?

Best regards,
Mikae= l

Den tis 14 jan. 2020 12:18Andy Wingo <wingo@pobox.com> skrev:
On Mon 13 Jan 2020 22:32, Stefan Israels= son 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

--0000000000000555e1059c1986a2--