From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 18:27:18 +0100 Message-ID: References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> <87pnfmglbo.fsf@pobox.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000001b6f2059c1ce844" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186835"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 18:27: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 1irPyj-000m5f-Hi for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 18:27:45 +0100 Original-Received: from localhost ([::1]:44026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPyi-0004bi-7l for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 12:27:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41304) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irPyW-0004ZS-HR for guile-devel@gnu.org; Tue, 14 Jan 2020 12:27:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irPyU-0007EW-Da for guile-devel@gnu.org; Tue, 14 Jan 2020 12:27:32 -0500 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:36873) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irPyU-0007EI-5U for guile-devel@gnu.org; Tue, 14 Jan 2020 12:27:30 -0500 Original-Received: by mail-wr1-x431.google.com with SMTP id w15so13046343wru.4 for ; Tue, 14 Jan 2020 09:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EkzGkY/eG/+U455hf/95rsMc/WmreG/oiZ1smYaYvvI=; b=Ydt6aShyF7R4GMn5eOyL5oKsjwey2mq4cE+o3utP8GoCwUlxJK1Q0IyJk1LtYX8WVm cRqUBPIACNCUM04gMOvlF8dsJ+aEWvsGBndUOzyymjgXEZcT6BgtkxycoGepJbCKn+dE uWPQ1oEQMArys0OnsotoHXukc27X69DdGXiEN4UYrTMl4kcZ2wX6IS+Pe//r4tjrxVDm SnDefe94DVHR4KZwPJojOdHwlPvpX/tpzUr1LpLLJjYnuzA0nEhYGRwk0McftSAD3Y6w 0YP6SLhherywkIb5x8jXJeTJN5AQKYl7CaPsimcY67+JQDVuWqWLLRLjhI1kWJMizMXx BmMg== 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:from:date :message-id:subject:to:cc; bh=EkzGkY/eG/+U455hf/95rsMc/WmreG/oiZ1smYaYvvI=; b=EhlLK7yC/wbKh+7mA26nxV5o3n20XyThbbqhuwxOyi68rh6ogjn+5PeOG5EML6+Dyz M2K50RNsDIDkcs/EUl9A/5G/lVdQaPr51RDeNvKVjXSXaYWlC+SXPQxNYCv+Ab3AlViv gbw4QrRgycne9pHTzZSxgBu1uCNgPRgipheK4dZsBPiZq16/9/1kI9JgcftAzzaWC+kt EAkk/OmmtoMqKLwS/At6kPHZoqeXXwluJ4xTrEWa94wd2fCm1v9anN6iTTYTLRYzbwkJ 7o6NMDm9miW5mjvMhVFVG0cUsNPagHZ6WG1OgSqbF78yBVE9qiYowR0/hy9if0Vi+mHo Sxcw== X-Gm-Message-State: APjAAAXM/sOaBZ6IHV/LdYl7urHC0l3dYPYSgISSYoXdQhZArp8aD8Ta q/oKCLor0sWSEiuJFlRDyPQm+Tqvc4/jZs7C6Ak= X-Google-Smtp-Source: APXvYqxRgVXVZLhVZhayMa8NrMzR7qQ84w6o3auCS7GUJvkP9mDKpXCkkY+SjjwGwPIpOYnEwyUX2qyGQGcTC13Z2HQ= X-Received: by 2002:adf:d4ca:: with SMTP id w10mr25086998wrk.53.1579022848996; Tue, 14 Jan 2020 09:27:28 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::431 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:20275 Archived-At: --00000000000001b6f2059c1ce844 Content-Type: text/plain; charset="UTF-8" I'm not stupid and I don't see any good reason why you cannot maintain a way to keep function identities. I could go as far as having a primitive to mark a procedure for keeping the identity. But No No, please apply the patch. For example the nice thing with python on guile is that python functions is also scheme functions and vice versa without the procedure identity (eq? f f) = #t you will need to wrap every single scheme call and totally destroy python on guile. It will be a mess. So I would probably not make a python on guile release for guile 3.0. Also Not guile log because it also is highly invested using procedures as hash keys. What I would probably do is to apply wingos patch and demand other who want guile 3.0 and python on guile and guile-log to do the same. Regards Stefan On Tue, Jan 14, 2020 at 5:47 PM 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> 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 >>>> >>> --00000000000001b6f2059c1ce844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not stupid and I don't s= ee any good reason why you cannot maintain a way to keep function identitie= s. I could go as far as having a primitive to mark a procedure for keeping = the identity.

But No=C2=A0 No, please apply the pa= tch. For example the nice thing with python on guile is that python functio= ns is also scheme functions and vice versa without the procedure identity (= eq? f f) =3D #t you will need
to wrap every single scheme cal= l and totally=C2=A0destroy python on guile. It will be a mess. So I would p= robably not make a python on guile release for guile 3.0. Also Not guile lo= g because it also
is highly invested using procedures as hash key= s. What I would probably do is to apply wingos patch and demand other who w= ant guile 3.0 and python on guile and guile-log to do the same.
=

Regards
Stefan

On Tue, Jan 14, 2020 at 5:47 PM= Mikael Djurfeldt <mikael@djurfe= ldt.com> wrote:
It might be reasonable to keep the patch for n= ow in order not to introduce novel behavior this short before the 3.0 relea= se.

But especially in light of Andy's work, I = do regret introducing procedure-properties. It's a more LISPy feature t= han Schemey. Did you see Andy's argument about procedure equality below= ?

I would have preferred to postpone the release a= nd drop procedure equality, procedure-properties etc. It can be handy and c= onvenient, 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 <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@djurf= eldt.com>


This is how it always ha= ve been in guile, without 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 procedures as keys to hashmap, nuke procedure propertie= s and friends or mark it as internal to avoid luring schemers into using a = faulty method. This patch improves the use of higher=C2=A0order 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=C2=A0natural way of programming. Without it you= need
to put the procedures in a datastructure and=C2=A0track tha= t datastructure that will uglify a lot of code. It is manageable=C2=A0but w= hen the opposite is similarly speeded code but much nicer and enjoyable cod= e with absolutely no risk in
higher order functionality countrary= as you state (because higher order worked=C2=A0flawlessly before in guile = and the patch is restoring that).

On Tue, Jan 14, 2020 at 5:07 PM Mika= el Djurfeldt <= mikael@djurfeldt.com> wrote:
Hmm... it seems like= both Stefan and you have interpreted my post exactly the opposite way comp= ared to how it was meant. :)

I comple= tely agree that procedure equality is not strongly connected to the first c= itizen-ness.

What I wanted to say is that I probab= ly prefer you to *reverse* the recent patch because I prefer to have good o= ptimization also when procedures are referenced by value in more than one n= on-operator position. I prefer this over having (eq? p p) =3D> #t for th= e reasons I stated.

Best regards,
Mikael=

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

=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
--00000000000001b6f2059c1ce844--