emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: pure-fns in byte-opt.el


From: Drew Adams
Subject: RE: pure-fns in byte-opt.el
Date: Sun, 24 Sep 2017 09:26:15 -0700 (PDT)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]