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 <mik...@djurfeldt.com>

> 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 <wi...@pobox.com> skrev:
>> 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