Fwd: GNU Guile 2.9.9 Released [beta]

2020-01-14 Thread Stefan Israelsson Tampe
-- Forwarded message -
From: Stefan Israelsson Tampe 
Date: Tue, Jan 14, 2020 at 5:23 PM
Subject: Re: GNU Guile 2.9.9 Released [beta]
To: Mikael Djurfeldt 


This is how it always have been in guile, without this patch you cannot use
procedure-property, use a function as a key to hash maps etc. If this patch
goes you need to forbid usage
of procedures as keys to hashmap, nuke procedure properties and friends or
mark it as internal to avoid luring schemers into using a faulty method.
This patch improves the use of higher order functions
not risk it. For example I often classify functions into different
categories and maintain this information as a property on the function via
a hashmap. This is a quite natural way of programming. Without it you need
to put the procedures in a datastructure and track that datastructure that
will uglify a lot of code. It is manageable but when the opposite is
similarly speeded code but much nicer and enjoyable code with absolutely no
risk in
higher order functionality countrary as you state (because higher order
worked flawlessly before in guile and the patch is restoring that).

On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt 
wrote:

> Hmm... it seems like both Stefan and you have interpreted my post exactly
> the opposite way compared to how it was meant. :)
>
> I completely agree that procedure equality is not strongly connected to
> the first citizen-ness.
>
> What I wanted to say is that I probably prefer you to *reverse* the recent
> patch because I prefer to have good optimization also when procedures are
> referenced by value in more than one non-operator position. I prefer this
> over having (eq? p p) => #t for the reasons I stated.
>
> Best regards,
> Mikael
>
> Den tis 14 jan. 2020 15:33Andy Wingo  skrev:
>
>> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt  writes:
>>
>> > 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.
>>
>> Is this true?
>>
>>   (eq? '() '())
>>
>> What about this?
>>
>>   (eq? '(a) '(a))
>>
>> And yet, are datums not first-class values?  What does being first-class
>> have to do with it?
>>
>> Does it matter whether it's eq? or eqv?
>>
>> What about:
>>
>>   (eq? (lambda () 10) (lambda () 10))
>>
>> What's the difference?
>>
>> What's the difference in the lambda calculus between "\x.f x" and "f"?
>>
>> What if in a partial evaluator, you see a `(eq? x y)`, and you notice
>> that `x' is bound to a lambda expression?  Can you say anything about
>> the value of the expression?
>>
>> Does comparing procedures for equality mean anything at all?
>> https://cs-syd.eu/posts/2016-01-17-function-equality-in-haskell
>>
>> Anyway :)  All that is a bit of trolling on my part.  What I mean to say
>> is that instincts are tricky when it comes to object identity, equality,
>> equivalence, and especially all of those combined with procedures.  The
>> R6RS (what can be more Schemely than a Scheme standard?) makes this
>> clear.
>>
>> All that said, with the recent patch, I believe that Guile 3.0's
>> behavior preserves your intuitions.  Bug reports very welcome!
>>
>> Andy
>>
>


Fwd: GNU Guile 2.9.9 Released [beta]

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


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  wrote:

> 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
>