From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Taylan Kammer Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 18:21:08 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> <87pnfmglbo.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="110488"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: guile-devel To: mikael@djurfeldt.com, Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 18:21:27 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1irPsc-000SEE-OM for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 18:21:26 +0100 Original-Received: from localhost ([::1]:43950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPsb-0001Oz-Jz for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 12:21:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39996) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPsP-0001NB-8v for guile-devel@gnu.org; Tue, 14 Jan 2020 12:21:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irPsN-0004cz-OI for guile-devel@gnu.org; Tue, 14 Jan 2020 12:21:13 -0500 Original-Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:52312) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irPsN-0004bR-EI for guile-devel@gnu.org; Tue, 14 Jan 2020 12:21:11 -0500 Original-Received: by mail-wm1-x331.google.com with SMTP id p9so14788915wmc.2 for ; Tue, 14 Jan 2020 09:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aPeNg4kD0bpsSmh/Dq+nokMgKH5RGIRfgkdkPKTghwM=; b=JXR7c7ZyrIzcrF3wNqpVA89AGNth/pvjZGWY/0nrX3NB7OK0S82ha11DHZ6hMSi5JX 7trg0T/lerAAGEUDgOjOnwb7E35M3ku+reokwpz7aberUYj55e1L/mTqC/FqdOEowJfs 1oTdlKE6xp8S7HQUjpqK5vs10KbNTDHNfDvPj6uGYEP3igZwaJ7FCmASZKYsjDxXAwQ0 ipQQywlxiDo1DnRKdfmCt+8+iZoaczg7fxr1o2WC410giAH90BFwlzzAn9aeW4XMt/XX BBlXo6VwLvr77+f2eVHwHV5fOyldLsXvTBobPgh7ajyoV0A6oEJ7nCFMsDAHHteh2jS4 kETw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aPeNg4kD0bpsSmh/Dq+nokMgKH5RGIRfgkdkPKTghwM=; b=JWBgZE/3OuwpL9q7KkeCGwDP7OQPItM5/oikamNsyUhcIbacYkyPRKLPaTZbEgk5rR +Uv2TQyXzFYmaSIS8/FRvrgjIwfEwLBR1+aS7z30xIqthEGPVIQsmLKfo6Z68fI/kM06 UdZ4H4x6s0/mSXXoOsGQx8xNxalzVgbi1lu+1W9xEzNh2RSfV76yF2MXwFoOpl0YJMD1 SfzVJpttMSAWtMwnmorCAU0TkuEO7dDbS/g0uhx+cvBMJaWFHmoZqF2jDRE6IIue6cx3 8BKqaO4jS/+/Ik+zskSpLPqwZK19Nq/eHtW6c+U0texkIcQU60ugSSz/PoMdie0jltTH 20EA== X-Gm-Message-State: APjAAAV1+Wcp6hJ5d3OPueB52nyHvtYPbVd/jTVugwP7ib0wce6+IDyB 2gs2ZB4iLQ/esWgBV6uMrN0EHjZC X-Google-Smtp-Source: APXvYqx4ZzJtj0/ZjXVPh3MECGAAwSYuEVeU5Qj/ujRsRsYzHPc652kZ+sXPZZ5HFqKHc/aRGbw2mg== X-Received: by 2002:a1c:4e03:: with SMTP id g3mr29362826wmh.22.1579022469491; Tue, 14 Jan 2020 09:21:09 -0800 (PST) Original-Received: from [192.168.16.136] (mail2.compnetgmbh.de. [37.24.177.210]) by smtp.gmail.com with ESMTPSA id q3sm18608779wmj.38.2020.01.14.09.21.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jan 2020 09:21:08 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::331 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20274 Archived-At: 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 > > wrote: > > > > ---------- 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 >