Re: GNU Guile 2.9.9 Released [beta]

[Taylan Kammer <taylan.kammer@gmail.com>]

During the R7RS-small discussion, I remember Will Clinger suggesting to
keep (eqv? proc1 proc2) => #t but unspecifying it for eq?.  Would that
help in Guile's case?  I don't remember the exact optimization he
suggested this for.


- Taylan

On 14.01.2020 17:47, Mikael Djurfeldt wrote:
> It might be reasonable to keep the patch for now in order not to
> introduce novel behavior this short before the 3.0 release.
> 
> But especially in light of Andy's work, I do regret introducing
> procedure-properties. It's a more LISPy feature than Schemey. Did you
> see Andy's argument about procedure equality below?
> 
> I would have preferred to postpone the release and drop procedure
> equality, procedure-properties etc. It can be handy and convenient, yes,
> but there is a reason why R6RS didn't require (eq? p p) -> #t...
> 
> Best regards,
> Mikael
> 
> On Tue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe
> <stefan.itampe@gmail.com <mailto:stefan.itampe@gmail.com>> wrote:
> 
> 
> 
>     ---------- Forwarded message ---------
>     From: *Stefan Israelsson Tampe* <stefan.itampe@gmail.com
>     <mailto:stefan.itampe@gmail.com>>
>     Date: Tue, Jan 14, 2020 at 5:23 PM
>     Subject: Re: GNU Guile 2.9.9 Released [beta]
>     To: Mikael Djurfeldt <mikael@djurfeldt.com
>     <mailto:mikael@djurfeldt.com>>
> 
> 
>     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
>     <mikael@djurfeldt.com <mailto:mikael@djurfeldt.com>> 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 <wingo@pobox.com
>         <mailto:wingo@pobox.com>> skrev:
> 
>             On Tue 14 Jan 2020 13:18, Mikael Djurfeldt
>             <mikael@djurfeldt.com <mailto:mikael@djurfeldt.com>> 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
>