Fwd: GNU Guile 2.9.9 Released [beta]

[Stefan Israelsson Tampe]

---------- Forwarded message ---------
From: Stefan Israelsson Tampe <address@hidden>
Date: Tue, Jan 14, 2020 at 12:43 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Andy Wingo <address@hidden>

Thanks!

Phew!

I think that for an f, a direct function application need not to be counted as a position. Only when you use f in a higher order manner

demands that you count this. E.g. (g f), (return f)

Regards

Stefan

On Tue, Jan 14, 2020 at 12:16 PM Andy Wingo <address@hidden> wrote:

On Mon 13 Jan 2020 22:32, Stefan Israelsson Tampe <address@hidden> 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