[Top][All Lists]

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

RE: Predicate for true lists

From: Drew Adams
Subject: RE: Predicate for true lists
Date: Wed, 17 Apr 2019 11:55:07 -0700 (PDT)

> this seems to be a near-identical case of bug#13823.

Indeed it does.

> I attach two patches.  The first updates the Elisp manual as discussed,
> and the second moves all side-effect-free property setting from
> unsafep.el to subr.el, as declarations of the relevant functions.  WDYT?

Thanks for working on this.  Some minor comments, in case they help (if not, 

1. Wrt this proposed addition:

+A @dfn{pure function} is a function which, in addition to having no
+side effects, always returns the same value for the same combination
+of arguments, regardless of external factors such as machine type.

You might want to add something like this at the end:

", current time/date, or state of the system or
Emacs session."

"Machine type" is not the first thing I'd think of in this
regard, and it doesn't emphasize current state in the context
of dynamic changes.  The result does not depend on any state.

2. It's usually better to just write "or" instead of "and/or".

3. I'd say "not encouraged" instead of "no longer encouraged".
There's no need here to suggest that it was encouraged in the

4. "side-effect free and pure" should just be "pure", given
that the xref'd node will now say that "pure" includes
"side-effect free".

5. "ignore calls whose value is unused" is maybe clearer as
"ignore a call whose value is unused" or "ignore calls whose
values are unused".  (I prefer the former.)

6. I'd use "can" instead of "may" for things like "the byte
compiler may...".  (Not very important, though.)  It's more
about possibility than permission.

reply via email to

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