From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: pure-fns in byte-opt.el Date: Wed, 26 Jul 2017 09:39:00 +0200 Message-ID: <7ef8e35a-d236-5158-f2eb-85f01da87a2e@gmail.com> References: <20170725020650.GA12601@holos.localdomain> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1501054753 21635 195.159.176.226 (26 Jul 2017 07:39:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Jul 2017 07:39:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Cc: Mark Oteiza , Andreas Schwab To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 26 09:39:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1daGuR-0005L2-L6 for ged-emacs-devel@m.gmane.org; Wed, 26 Jul 2017 09:39:07 +0200 Original-Received: from localhost ([::1]:36537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daGuX-0001uY-Ct for ged-emacs-devel@m.gmane.org; Wed, 26 Jul 2017 03:39:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daGuQ-0001uD-OS for emacs-devel@gnu.org; Wed, 26 Jul 2017 03:39:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1daGuM-0000Bm-Pd for emacs-devel@gnu.org; Wed, 26 Jul 2017 03:39:06 -0400 Original-Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:37263) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1daGuM-0000AD-IV for emacs-devel@gnu.org; Wed, 26 Jul 2017 03:39:02 -0400 Original-Received: by mail-wm0-x234.google.com with SMTP id c184so73910217wmd.0 for ; Wed, 26 Jul 2017 00:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Xrx4vDfVKJp8gvdRZ8yoaEh6Y9l8CpnN5uPKVXemaM8=; b=t/NJoxweKkiaV97iLSb1rMb99Q7ADYrPjt2nbZPatQQ6rdT5/Ouj4fTI0y2N66cv+g k2PzFhUsQCQPAiqiXKK98gCR97R3vf/hZWZOVwI6JKFq9HPq2tGPoFrREP07A5MKM0Zi 05UqFVzs3shoV9ALL5xGLUJSQLVcI3EMNqiYcn2so3UbXsV1ltcQopg16eV0aCTCmfKm bLVDxhHEDcyBgLE35YOn5HhBgtRvEUMjNQXBX4pFr3dvp6BC2GRA7pf/PF08Hy1Izf/5 63xmTv4g3619a7bbc+ZGC1NyyxxpC+UmnmohkfwYrNZmCgg5tfTc978BJ3kH3/nS5Oxe WlGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xrx4vDfVKJp8gvdRZ8yoaEh6Y9l8CpnN5uPKVXemaM8=; b=lZE2CHuY17xWHnDcUZTi2lr1LjrMfIpomtmDWSnvqLaFDjNA9sLy6wSW9DGgeI632c i5K/DQCq3WIviFSRkLDTWhM/zc37b6OISOEsoVF1ldbfP6zFc6retgqDP3Bl/L32nKJV T3B0gL0fjDxu9ly+lwHzRwN5VaCCf9CbTtMsY1it2VUXxSSv6FhLckqtljSomtVfgs7d eyxAXkwWSgaOvd6qZKX6dMYRvhqozXDmOBlrSTwIx64OqA/Euk2pdoi9nFTrSA4ZxwnP JlErPgEbdXpg8V1obetRq1up7vqIuxHcGsrhwX+fOH0GEiT6jSURkpm0m2Kvi+nDg3bG 4gkQ== X-Gm-Message-State: AIVw113jE1Wc350IbXR7KwDevGWMJjke3wqj51JjbZsluWMW44yJaF3z Y4XgvNSmQfbSeA== X-Received: by 10.28.101.5 with SMTP id z5mr2620wmb.136.1501054741341; Wed, 26 Jul 2017 00:39:01 -0700 (PDT) Original-Received: from [128.93.82.216] ([128.93.82.216]) by smtp.gmail.com with ESMTPSA id b80sm12478777wmf.10.2017.07.26.00.39.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 00:39:00 -0700 (PDT) In-Reply-To: Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217035 Archived-At: On 2017-07-26 02:08, Stefan Monnier wrote: >>> If string-to-char were a pure function, it would return the same >>> value in both calls (since the arguments are `eq') >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> What do you mean by this? > > That the argument passed to the first call is `eq` with the argument > passed to the second call. I see. That's not what I understood to be usually meant by "pure": although both arguments are pointers to the same address in memory, the contents of that address have been modified in the meantime. In that sense, haven't the two calls to string-to-char been passed different values (albeit stored in the same memory location)? In other words, I don't see your example as proving that string-to-char is impure; instead, it just looks like a pure function that's passed two different values. As a concrete example, is the following a proof that string-to-syntax is impure? If so, it should be removed from our list of pure functions :) (let ((s (make-string 1 ?w))) (list (string-to-syntax s) (progn (aset s 0 ?_) (string-to-syntax s)))) The same argument seems to apply to *all* functions marked pure in byte-opt.el, except `symbol-name' (namely `concat', `regexp-opt', `regexp-quote', and `string-to-syntax'). Under your definition, neither the `length' nor the `car' function on lists are pure. In fact, if I understand it correctly, your definition seems to imply that any function that reads mutable data is (by definition) impure. Is that right? This seems very restrictive, and it seems to be contradicted by existing 'pure' annotations in our codebase. How do we call the property shared by `concat', `length', and `string-to-chars'? in ELisp land, if it's not "pure"? In byte-opt we say this: ;; pure functions are side-effect free functions whose values depend ;; only on their arguments. For these functions, calls with constant ;; arguments can be evaluated at compile time. This may shift run time ;; errors to compile time. I tried to get inspiration from looking at other `pure' annotations in lisp/ but the examples I found were confusing. All four examples of (pure t) functions in smie.el take lists as input, for example: (defun smie-precs->prec2 (precs) "Compute a 2D precedence table from a list of precedences. … (declare (pure t)) and indeed: (let ((s '((left "+") (right "*")))) (list (smie-precs->prec2 s) (progn (setf (caar s) 'right) (smie-precs->prec2 s)))) Can you point out where I went wrong? To me it just looks like Mark ran into a bug. Clément.