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.ita...@gmail.com <mailto:stefan.ita...@gmail.com>> wrote: > > > > ---------- Forwarded message --------- > From: *Stefan Israelsson Tampe* <stefan.ita...@gmail.com > <mailto:stefan.ita...@gmail.com>> > Date: Tue, Jan 14, 2020 at 5:23 PM > Subject: Re: GNU Guile 2.9.9 Released [beta] > To: Mikael Djurfeldt <mik...@djurfeldt.com > <mailto:mik...@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 > <mik...@djurfeldt.com <mailto:mik...@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 <wi...@pobox.com > <mailto:wi...@pobox.com>> skrev: > > On Tue 14 Jan 2020 13:18, Mikael Djurfeldt > <mik...@djurfeldt.com <mailto:mik...@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 >