---------- Forwarded message ---------
From: Stefan Israelsson Tampe <stefan.ita...@gmail.com>
Date: Tue, Jan 14, 2020 at 12:43 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Andy Wingo <wi...@pobox.com>



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)


On Tue, Jan 14, 2020 at 12:16 PM Andy Wingo <wi...@pobox.com> wrote:

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

Reply via email to