From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 17:47:27 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> <87pnfmglbo.fsf@pobox.com> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008bff7e059c1c5901" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="26083"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 17:51:48 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 1irPPv-0006Ol-Cc for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 17:51:47 +0100 Original-Received: from localhost ([::1]:43356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPPt-0000NZ-Ph for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 11:51:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33143) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPLy-0006If-VI for guile-devel@gnu.org; Tue, 14 Jan 2020 11:47:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irPLw-0003OD-0m for guile-devel@gnu.org; Tue, 14 Jan 2020 11:47:42 -0500 Original-Received: from mail-vk1-f171.google.com ([209.85.221.171]:40421) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irPLv-0003N6-Rn for guile-devel@gnu.org; Tue, 14 Jan 2020 11:47:39 -0500 Original-Received: by mail-vk1-f171.google.com with SMTP id c129so3810972vkh.7 for ; Tue, 14 Jan 2020 08:47:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Q8rgmYn+1IZVcRIdmM/HZem4tc88odojW2FIXN4isNY=; b=jdiXULHStkKKkVmh0TmFe34KxZGFCfv/td7HBV65B6TiaOZmH9L6QXdB9X/zjWbR7f JOPTA9nLs6VoV8dcSCoSF0ynTBSAgXbvxGekd8hZFRUceanW726wDJkvofiszwuv/1Tq Wqs2atVJ7TtfnTl1ExI9qSb6gF/QP41h7KgNkAueUuom3Vj7ziEccmC+1ZEVk19uzNMx 3AqZqajHy120mxzcgrMyOqQB+scpkVWqVdO4x9DbtvYXVWoD3Wtw/3T+MnRQki2RUr4w BqcxE+Ya1R6uPekDQehMxT9AXaaoG9CUnkluTZiOdWN4AzV8ZDlN7epdVrJL23sMWQQF yNvw== X-Gm-Message-State: APjAAAVMDZjKfJIxg8MBwFBBpeik7v6DznqJrOGFh/A7aPuoEYld7ZKW PwNUW9+myynz3Kg82JUCoO/qv6ha+cWY3AfmKXo= X-Google-Smtp-Source: APXvYqykus8MRxaWl8H2LAbE9VPxPKrSDPNV66rOoiXlvnvApgvwsCf9EiZ+WqpwqRyLZ4tFE9T9d7N9g3/flyj8e3c= X-Received: by 2002:a1f:18b:: with SMTP id 133mr11205054vkb.73.1579020458916; Tue, 14 Jan 2020 08:47:38 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.221.171 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:20273 Archived-At: --0000000000008bff7e059c1c5901 Content-Type: text/plain; charset="UTF-8" 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> 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 >>> >> --0000000000008bff7e059c1c5901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might be reasonable to keep the patch for now in o= rder not to introduce novel behavior this short before the 3.0 release.

But especially in light of Andy's work, I do regr= et introducing procedure-properties. It's a more LISPy feature than Sch= emey. 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 convenie= nt, yes, but there is a reason why R6RS didn't require (eq? p p) -> = #t...

Best regards,
Mikael

On T= ue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:


---------- Fo= rwarded message ---------
From: Stefan Israelsson Tampe <stefan.itampe@gmail.c= om>
Date: Tue, Jan 14, 2020 at 5:23 PM
Subject: Re: GNU= Guile 2.9.9 Released [beta]
To: Mikael Djurfeldt <mikael@djurfeldt.com>


This is how it always have been in guile, witho= ut this patch you cannot use procedure-property, use a function as a key to= hash maps etc. If this=C2=A0patch goes you need to forbid usage
of pro= cedures as keys to hashmap, nuke procedure properties and friends or mark i= t as internal to avoid luring schemers into using a faulty method. This pat= ch improves the use of higher=C2=A0order functions
not risk it. F= or example I often classify functions into different categories and maintai= n this information as a property on the function via a hashmap. This is a q= uite=C2=A0natural way of programming. Without it you need
to put = the procedures in a datastructure and=C2=A0track that datastructure that wi= ll uglify a lot of code. It is manageable=C2=A0but when the opposite is sim= ilarly speeded code but much nicer and enjoyable code with absolutely no ri= sk in
higher order functionality countrary as you state (because = higher order worked=C2=A0flawlessly before in guile and the patch is restor= ing that).

On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
Hmm... it seems like both Stefan and you ha= ve interpreted my post exactly the opposite way compared to how it was mean= t. :)

I completely agree that procedu= re equality is not strongly connected to the first citizen-ness.
=
What I wanted to say is that I probably prefer you to *rever= se* the recent patch because I prefer to have good optimization also when p= rocedures are referenced by value in more than one non-operator position. I= prefer this over having (eq? p p) =3D> #t for the reasons I stated.

Best regards,
Mikael

Den tis 14 ja= n. 2020 15:33Andy Wingo <wingo@pobox.com> skrev:
On Tue 14 Jan 2020 13:18, Mikael Djurfeldt <mikae= l@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?

=C2=A0 (eq? '() '())

What about this?

=C2=A0 (eq? '(a) '(a))

And yet, are datums not first-class values?=C2=A0 What does being first-cla= ss
have to do with it?

Does it matter whether it's eq? or eqv?

What about:

=C2=A0 (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?=C2=A0 Can you say anything ab= out
the value of the expression?

Does comparing procedures for equality mean anything at all?
https://cs-syd.eu/posts/20= 16-01-17-function-equality-in-haskell

Anyway :)=C2=A0 All that is a bit of trolling on my part.=C2=A0 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.=C2=A0 Th= e
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.=C2=A0 Bug reports very welcome!

Andy
--0000000000008bff7e059c1c5901--