all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Philipp Stephani <p.stephani2@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel@gnu.org
Subject: RE: pure-fns in byte-opt.el
Date: Sun, 24 Sep 2017 09:26:15 -0700 (PDT)	[thread overview]
Message-ID: <0be371fd-9212-4c42-9c17-3038c0b3d8a1@default> (raw)
In-Reply-To: <CAArVCkQ02yOBuuB=ceDD8WV--XbttqzLXP2stv2ic61v+PuKSg@mail.gmail.com>

> 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.

Not sure what you intend by the "symbol cells" of dynamic
variables.  Do you mean only their `symbol-value' values?

Or do you mean all properties of the symbols that serve as
dynamic variables?

Or do you perhaps mean all properties of all symbols (dynamic
variable or not)?

>   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.

There are tons of other kinds of side effects possible in
Lisp, of course.  A "side-effect-free function" per your
definition can perform any number of other such side effects.

It can affect symbol properties, string properties, buffer
properties, cons cells,....

What's the intended purpose of your "side-effect-free"
function?

If your definition of it is sufficient for that purpose
then please consider using some other name for the quality
you define, as it is really quite far from characterizing
a side-effect-free Lisp function, i.e., far from indicating
that a given Lisp function (so-called) performs no side
effects.

> 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.

Just accepts and returns?  What about modifying buffers or
processes without accepting them as arguments or returning
them?

A Lisp function invocation exists in an environment that
goes far beyond the current values and definitions of the
current set of variables and functions.

The behavior of such an invocation can be affected by any
number of aspects of that environment, and it can (side-)
effect any number of them.

> - 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'.

In Lisp, "functions" are not just about arguments and return
values.  Lisp is as procedural and imperative as Fortran, C,
or assembler.

But again, maybe your intended use of "pure" Lisp functions,
following your definition, does not really require actually
pure functions.  If so, please consider using some other name
for the quality you are calling "pure", as it is really quite
far from characterizing a pure function.



  parent reply	other threads:[~2017-09-24 16:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25  2:06 pure-fns in byte-opt.el Mark Oteiza
2017-07-25  8:14 ` Andreas Schwab
2017-07-25 14:16   ` Stefan Monnier
2017-07-25 20:57     ` Philipp Stephani
2017-07-25 21:27       ` Stefan Monnier
2017-07-25 22:28         ` Clément Pit-Claudel
2017-07-26  0:08           ` Stefan Monnier
2017-07-26  7:39             ` Clément Pit-Claudel
2017-07-26 12:58               ` Stefan Monnier
2017-07-28 17:45         ` Philipp Stephani
2017-07-28 17:49           ` Stefan Monnier
2017-07-28 17:52             ` Philipp Stephani
2017-07-28 22:20               ` Stefan Monnier
2017-09-24  7:31                 ` Philipp Stephani
2017-09-24 16:23                   ` Stefan Monnier
2017-09-25 22:06                     ` Richard Stallman
2017-09-26  0:25                       ` Stefan Monnier
2020-07-25 19:53                         ` Philipp Stephani
2020-07-25 19:58                           ` Stefan Monnier
2020-07-25 20:08                             ` Philipp Stephani
2020-07-25 20:59                               ` Stefan Monnier
2020-07-29 14:21                                 ` Philipp Stephani
2020-07-29 14:25                                   ` Stefan Monnier
2017-09-24 16:26                   ` Drew Adams [this message]
2017-07-26  1:00   ` Mark Oteiza
2017-07-26 14:33     ` Eli Zaretskii
2017-07-27  2:36       ` Mark Oteiza
2017-07-27  2:46         ` Stefan Monnier
2017-07-29 16:43           ` Mark Oteiza
2017-07-29 17:22             ` Eli Zaretskii
2017-07-29 19:48               ` Mark Oteiza
2017-07-29 20:03                 ` Andreas Schwab
2017-07-29 20:14                   ` Mark Oteiza
2017-07-27 17:06         ` Eli Zaretskii
2017-07-28  0:24           ` Mark Oteiza
2017-07-28  7:02             ` Eli Zaretskii
2017-07-29  1:24               ` Mark Oteiza
2017-07-29  7:24                 ` Eli Zaretskii
2017-07-29 16:34                   ` Mark Oteiza
2017-07-29 17:21                     ` Eli Zaretskii
2017-09-24  7:34                       ` Philipp Stephani
2017-09-24 16:24                         ` Stefan Monnier
2017-09-24 23:22                         ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0be371fd-9212-4c42-9c17-3038c0b3d8a1@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.