[Top][All Lists]

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

Re: Predicate for true lists

From: Basil L. Contovounesios
Subject: Re: Predicate for true lists
Date: Wed, 10 Apr 2019 15:34:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Alex Branham <address@hidden> writes:

> On Wed 10 Apr 2019 at 05:32, Eli Zaretskii <address@hidden> wrote:
>>> From: "Basil L. Contovounesios" <address@hidden>
>>> Date: Tue, 09 Apr 2019 21:12:49 +0100
>>> Cc: address@hidden
>>> diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi
>>> index 8ebe47d9ad..826818c380 100644
>>> --- a/doc/lispref/internals.texi
>>> +++ b/doc/lispref/internals.texi
>>> @@ -1031,10 +1031,13 @@ Writing Emacs Primitives
>>>  @file{lisp.h} contains the definitions for some important macros and
>>>  functions.
>>> -  If you define a function which is side-effect free, update the code
>>> -in @file{byte-opt.el} that binds @code{side-effect-free-fns} and
>>> address@hidden so that the compiler optimizer
>>> -knows about it.
>>> +  If you define a function which is side-effect free, give it a
>>> address@hidden @code{side-effect-free} declaration (@pxref{Declare
>>> +Form}) or function property (@pxref{Symbol Plists}) so that the
>>> +compiler optimizer knows about it.  Alternatively, you can update the
>>> +code in @file{byte-opt.el} that binds @code{side-effect-free-fns} and
>>> address@hidden, but this approach is less
>>> +modular and no longer encouraged.
>> This should have a @cindex entry for "side-effect-free" and other
>> symbols referenced here.  Bonus points for adding some minimal
>> explanation what does "side-effect free function" mean.
>> Thanks.
> Isn't this in direct contradiction with (info "(elisp) Standard
> Properties") which states that side-effect-free should not be set?:
> ‘side-effect-free’
>      A non-‘nil’ value indicates that the named function is free of
>      side-effects, for determining function safety (*note Function
>      Safety::) as well as for byte compiler optimizations.  Do not set
>      it.

No, because the audience of (info "(elisp) Standard Properties") is the
average Elisp author, whereas the audience of (info "(elisp) Writing
Emacs Primitives") is the average contributor to Emacs core.

Currently, the side-effect-free property seems to be intended as an
internal one, since it makes some pretty strong guarantees, and is
described only in the commentary and code of byte-opt.el.  This is my
interpretation of the "Do not set it" wording.

Unless someone beats me to it, I intend to try to clarify this in the
next version of my patch.



reply via email to

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