Re: Predicate for true lists

[Basil L. Contovounesios]

Drew Adams <address@hidden> writes:

>> 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, 
> ignore):
>
> 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.

Right.  Would "machine type or system state" suffice?  I think this
covers time/date, etc.

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

Done.

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

This sentence will be removed altogether.

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

Done.

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

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

Yes, but may/might are about both possibility and permission, and can is
about both possibility and ability.  The former combination seems more
appropriate to me in this case, but I'm not opposed to changing it.

Thanks,

-- 
Basil