From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: pure-fns in byte-opt.el Date: Sun, 24 Sep 2017 07:31:42 +0000 Message-ID: References: <20170725020650.GA12601@holos.localdomain> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d6412997e700559ea6f68" X-Trace: blaine.gmane.org 1506238319 27529 195.159.176.226 (24 Sep 2017 07:31:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2017 07:31:59 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 09:31:56 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 1dw1ON-0006qG-6k for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 09:31:55 +0200 Original-Received: from localhost ([::1]:37184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dw1OU-0004rq-HB for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 03:32:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dw1ON-0004rh-86 for emacs-devel@gnu.org; Sun, 24 Sep 2017 03:31:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dw1OM-0000iJ-45 for emacs-devel@gnu.org; Sun, 24 Sep 2017 03:31:55 -0400 Original-Received: from mail-oi0-x236.google.com ([2607:f8b0:4003:c06::236]:47481) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dw1OL-0000hr-Tr for emacs-devel@gnu.org; Sun, 24 Sep 2017 03:31:54 -0400 Original-Received: by mail-oi0-x236.google.com with SMTP id b1so3325133oih.4 for ; Sun, 24 Sep 2017 00:31:53 -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; bh=tNNkV6wtiXNZSYO4MbQNc/TpKHWVvO9E08qtfMiZ6Bw=; b=vMhiQ/cH0oIcsabMZGd45ikx2i6pm4z/anrh9vl/tK0UnBQbYoD8x8clIRuLYcl6PH LrUk+GyUfRwFTR3MZtR3ctxfoaJGyagqs7WD3bxjJvcl+/4csLyqctbZqIZNO95niLF/ p+xUc916dm/IQcYHRyZIRuFHTzHQniJEtd2wv/Qo/2IYlUWi4eMUxQv2DWlsPQjrsjnT mQqhFGjXbIRlYVtes3b5d+ndijCPZ/UDEBqUC3Xe6t+QKKx9OzknkzZyUrz2J3IcEoRz 73YW6omyfuL9QfN4DPq3AHNWcl3Ucluz4IpyCOSx28G/Iso7ekfN4sYkBOFjBdaeu/LW H2qg== 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; bh=tNNkV6wtiXNZSYO4MbQNc/TpKHWVvO9E08qtfMiZ6Bw=; b=B00HIWxeCBQFlNswR8WurSW1gMnwUbMfZ5ta8gKgrMq1JOsgXfU/PJJ3QP2Z0o05bJ z97sbQIrGPj+XQqqeBjXzp7iUkbzdGDlDZZGl0wYxqZpWMaP6XkxTdfgSxK51DbZ77fy vNIv6DK9PnJmMnABBP8fmccR6TNVZDLDNERS0r3POsfjshnpG6TSrLBAmiiojmfGiVWF 1wvfxLhX8RDVUhXMe2QtGfXuah89HnV31J11OvNyhOp/Lm70chU4POAjQf93KXJ+WAX0 ky103MsRL8/xxM9PB+Ssyz026MyCIIk97IVm6X2xNAx8pgYlTY26Degq4WvLZKy/NFax ZzGg== X-Gm-Message-State: AHPjjUikghZNrAT6z/sJCy1BJoFt7q8jOJuPZBipLv/BmyuOp/6vGIyr 2y2vT5heSo4VnIodAh6ehqWvpd54vVwBxcobmgQ= X-Google-Smtp-Source: AOwi7QCQfSjquQtqUwuOIGvbhW6G1LjGlGpLOuTBY0x9YrwwOh36lYGubk7ipyV70AHcOnYzy+rBA2prmwk8/dn6KKU= X-Received: by 10.202.216.198 with SMTP id p189mr4490845oig.32.1506238313100; Sun, 24 Sep 2017 00:31:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::236 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:218737 Archived-At: --001a113d6412997e700559ea6f68 Content-Type: text/plain; charset="UTF-8" Stefan Monnier schrieb am Sa., 29. Juli 2017 um 00:21 Uhr: > > So what is then the actual definition? Is it in the manual? > > The only definition I've seen just says that it means that the compiler > can precompute the calls if it knows the arguments's values. > > Can we find a definition that allows authors of functions to derive their "pure" and "side-effect-free" status by only looking at their interface and implementation? It seems like these attributes would both be useful for documentation purposes as well as for optimization, and they have seen some use outside of Emacs core (e.g. in dash.el), so their semantics should be formalized and documented. How about something like this: A side-effect-free function is one where all of the following is true: - After exiting the function (whether normally or nonlocally), the `match-data' are `equal' to the `match-data' before entering the function. - After exiting the function, all dynamic variables, their default values, their symbol cells, etc., are `eq' to the respective values before entering the function. Exceptions are variables only used for debugging/tracing, such as `cons-cells-consed'. - All buffer contents, markers, point values etc. are `equal-including-properties' to their previous values. - The same buffers and threads still exist. A side-effect-free-and-error-free function is one that is side-effect-free and also doesn't signal any errors except `memory-full'. A pure function is a side-effect-free function with the following additional properties: - The function recursively only accepts and returns numbers, symbols, lists, vectors, hashtables, and strings; not buffers or processes since they are naturally stateful. - Two invocations with arguments that are pairwise `equal-including-properties' (or, in the case of hashtables, have keys and values that are `equal-including-properties') will either both exit nonlocally or return values that are again `equal-including-properties'. --001a113d6412997e700559ea6f68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stefan Monnier= <monnier@= iro.umontreal.ca> schrieb am Sa., 29. Juli 2017 um 00:21=C2=A0Uhr:
> So what is then the actual defi= nition? Is it in the manual?

The only definition I've seen just says that it means that the compiler=
can precompute the calls if it knows the arguments's values.


Can we find a definition that allows authors of functions to derive= their "pure" and "side-effect-free" status by only loo= king at their interface and implementation? It seems like these attributes = would both be useful for documentation purposes as well as for optimization= , and they have seen some use outside of Emacs core (e.g. in dash.el), so t= heir semantics should be formalized and documented. How about something lik= e this:

A side-effect-free function is one where a= ll of the following is true:
- After exiting the function (whethe= r normally or nonlocally), the `match-data' are `equal' to the `mat= ch-data' before entering the function.
- After exiting the fu= nction, all dynamic variables, their default values, their symbol cells, et= c., are `eq' to the respective values before entering the function. Exc= eptions are variables only used for debugging/tracing, such as `cons-cells-= consed'.
- All buffer contents, markers, point values etc. ar= e `equal-including-properties' to their previous values.
- Th= e same buffers and threads still exist.

A side-eff= ect-free-and-error-free function is one that is side-effect-free and also d= oesn't signal any errors except `memory-full'.

=
A pure function is a side-effect-free function with the following addi= tional properties:
- The function recursively only accepts and re= turns numbers, symbols, lists, vectors, hashtables, and strings; not buffer= s or processes since they are naturally stateful.
- Two invocatio= ns with arguments that are pairwise `equal-including-properties' (or, i= n the case of hashtables, have keys and values that are `equal-including-pr= operties') will either both exit nonlocally or return values that are a= gain `equal-including-properties'.
--001a113d6412997e700559ea6f68--