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.
next prev 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
List information: https://www.gnu.org/software/emacs/
* 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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).