From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations? Date: Sat, 25 Jul 2020 19:09:30 +0200 Message-ID: References: <3A9CC2A3-8307-47B2-8D80-795C0AF020E1@acm.org> <0433A879-C98D-4B1A-B85C-A15DA9289099@acm.org> <1621669100.2102667.1593639091621@mail.yahoo.com> <33C2E2C8-16A6-47A9-B3A4-8A5F43648E04@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34473"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , Stefan Monnier , Andrea Corallo , 42147@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 25 19:10:09 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jzNgX-0008s3-Mw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jul 2020 19:10:09 +0200 Original-Received: from localhost ([::1]:42506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jzNgW-0008PU-P3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jul 2020 13:10:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jzNgQ-0008PM-N5 for bug-gnu-emacs@gnu.org; Sat, 25 Jul 2020 13:10:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39497) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jzNgQ-0003NC-Ck for bug-gnu-emacs@gnu.org; Sat, 25 Jul 2020 13:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jzNgQ-0006MQ-8L for bug-gnu-emacs@gnu.org; Sat, 25 Jul 2020 13:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jul 2020 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42147 X-GNU-PR-Package: emacs Original-Received: via spool by 42147-submit@debbugs.gnu.org id=B42147.159569699224429 (code B ref 42147); Sat, 25 Jul 2020 17:10:02 +0000 Original-Received: (at 42147) by debbugs.gnu.org; 25 Jul 2020 17:09:52 +0000 Original-Received: from localhost ([127.0.0.1]:51043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzNgG-0006Lx-8D for submit@debbugs.gnu.org; Sat, 25 Jul 2020 13:09:52 -0400 Original-Received: from mail-oi1-f196.google.com ([209.85.167.196]:37274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzNgB-0006Lh-Q4 for 42147@debbugs.gnu.org; Sat, 25 Jul 2020 13:09:51 -0400 Original-Received: by mail-oi1-f196.google.com with SMTP id 12so10828977oir.4 for <42147@debbugs.gnu.org>; Sat, 25 Jul 2020 10:09:47 -0700 (PDT) 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:content-transfer-encoding; bh=zzo5Wa95pyFnsQkfeKq9Csd/xFh7nZ+xRE+f3SUAnNk=; b=geoUBgXPoA4Px8ZsMS5PVg5aGSBOq7gYKtla70O55tySfeGg5JuR6loIlQlcJNlEG6 Abd+DqhJdvBKk9/6dCMe8+9p1DWVLJ2DjuPCvUoZlMsilOHfYKj5DUsfQuvld3da2qgg 0uaKBoJKRhkQPDNPbVJ6Hgfl20omR1Wkc/CoxCAPuVc2fiYNK/XRi84+Ha763042O/wC hAgkEQ3LYvAuZmIjajHq0A49D38eH3MjuCbb1fc9SPrwUlh8GmmVNAdWIvawmLkyRY9x HjPMeGI0dLzjXmM0MQ8QpHT1nzr6ss1huwKzpgT5hPAZ4rXdg0pg+07Q9n5acPhia77H +J4Q== 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:content-transfer-encoding; bh=zzo5Wa95pyFnsQkfeKq9Csd/xFh7nZ+xRE+f3SUAnNk=; b=uM8n3EK//fhI8V4WelYmyzNdbuLziZDhC2UkqosevqWf+Kd5JxlkMuP6Vhd43iANQ8 MwgYfDKfzZrdLqbjJS/vFh7tl1dHhr315TEKjw2B1uDeJ9gVEKJ8bqGAA9v5BEKkZDR5 GOLIQbKzkiyJF60szxT2KFxE0Veg+Y5cWVEwcRzFklaB30vzpRr5hrQT5/PlZICzNDTV KAvnKuA2setacxVwh2GIH7rr8cmBP68dizU+RbhU7Kv5bSbFwMSv0hjnzAYLpV+H+YNq e2R+E5l8QfeGBMvXogZZCzP24+Sz1QcGfnuOlHhh/MamfoWLSE68PXVVnAmcFqB6GoJZ MthA== X-Gm-Message-State: AOAM533L1f/+rXI6j+0k05dLwfwgtj7EXX8Nt98I+72TX9UaKVyI2g1e y6x/3AnpjIoomH1Rg7d75R1RdXRJ8yCU+aOsisI= X-Google-Smtp-Source: ABdhPJxPNA5qNXvs3ZcEUFb/a9TyZzAIx9ylAmEZG8ZWkcMI61ZDyBEziBKD7JwO48L69FAwmP1HlA7ABWhSDnN/bkk= X-Received: by 2002:aca:b884:: with SMTP id i126mr12462304oif.65.1595696982081; Sat, 25 Jul 2020 10:09:42 -0700 (PDT) In-Reply-To: <33C2E2C8-16A6-47A9-B3A4-8A5F43648E04@acm.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:183531 Archived-At: Am Fr., 3. Juli 2020 um 11:25 Uhr schrieb Mattias Engdeg=C3=A5rd : > > 2 juli 2020 kl. 21.09 skrev Philipp Stephani : > > > I don't think most of those are pure, as they have to "look into" an > > object. For example, the result of "equal" does not only depend on the > > argument objects, but also the objects they refer to. > > Unless I'm mistaken, they are pure enough for the purpose of constant fol= ding, where the arguments are already known (constant) at compile-time; do = come with a counter-example if you disagree. > > Were you thinking about other uses of pure functions? Perhaps our notion = of purity is underspecified. > Yes, I think so. The term is mentioned in the Lisp manual, but I've always had trouble deciding whether a given function was pure or not. To be useful, the definition shouldn't depend on what the byte compiler happens to do; rather, we need to formally define purity (and side effect-freedom) based on the observable behavior of the function in question alone and then adapt the behavior of the byte compiler to the definition, if necessary. My working hypothesis is that "pure" is like GCC's "const" (https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html) and "side-effect free" is like GCC's "pure." That is, a side-effect free function can dereference pointers stored in Lisp_Objects, but a pure function can't. So functions like consp or eq are pure, while car or equal are merely side-effect free. eql is a bit of an exception, as floating-point objects and big integers are truly immutable, so it probably also qualifies as pure using this definition.