Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Stefan Monnier]

>     * lisp/emacs-lisp/byte-opt.el (side-effect-free-fns): Remove 'assoc'.

Oh, indeed: nasty.  `assoc` *was* side-effect-free until it grew its new
`testfn` argument.


        Stefan

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Mattias Engdegård]

31 okt. 2020 kl. 16.06 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> Oh, indeed: nasty.  `assoc` *was* side-effect-free until it grew its new
> `testfn` argument.

We do have a number of functions that are pure or side-effect-free unless given certain arguments. I suppose we could design a system that encompasses these cases. Certainly wouldn't mind algebraic effect types!

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Andrea Corallo via Emacs development discussions.]

Mattias Engdegård <mattiase@acm.org> writes:

> 31 okt. 2020 kl. 16.06 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>
>> Oh, indeed: nasty.  `assoc` *was* side-effect-free until it grew its new
>> `testfn` argument.
>
> We do have a number of functions that are pure or side-effect-free
> unless given certain arguments. I suppose we could design a system
> that encompasses these cases. Certainly wouldn't mind algebraic effect
> types!

Hi Mattias,

just ot mention, would be nice if we design this to be accessible so we
can use it in the native compiler as well maintaining it just in one
place.

  Andrea

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Mattias Engdegård]

1 nov. 2020 kl. 10.47 skrev Andrea Corallo via Emacs development discussions. <emacs-devel@gnu.org>:

> just ot mention, would be nice if we design this to be accessible so we
> can use it in the native compiler as well maintaining it just in one
> place.

It wasn't really meant seriously, but a simple system may look like

EFFECT ::=
   nil        ; no effect (subset of all effects)
 | *          ; any effect (superset of all effects)
 | signal     ; signal any condition (error etc)
 | read-env   ; read from the global environment
 | N          ; effect of function passed as argument N, N≥1
 | (union EFFECT...)  ; union of effects

Then today's declarations correspond to the effects:

pure              ~  signal
side-effect-free  ~  (union signal read-env)
error-free        ~  read-env

and the effects of 'assoc' would be (union signal 3).

More fine-grained effects could be added, such as throws, mutation of arguments, reading data referenced by arguments, etc.

It all depends on what is useful for the compiler(s) and related tools.

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Stefan Monnier]

> It wasn't really meant seriously, but a simple system may look like
>
> EFFECT ::=
>    nil        ; no effect (subset of all effects)
>  | *          ; any effect (superset of all effects)
>  | signal     ; signal any condition (error etc)
>  | read-env   ; read from the global environment
>  | N          ; effect of function passed as argument N, N≥1
>  | (union EFFECT...)  ; union of effects

Side note: this sounds good (I've been thinking along very similar lines
recently to try and improve the docs of `pure` and `side-effect-free`),
but note that nil has to me "any effect" since most functions will come
with no annotation at all (which most is most naturally mapped to nil).

Also, there are a few functions which we're willing to constant-fold
even though they can have "minor" side-effects (the cases I can think of
seem to be mostly about clobbering the match-data, so maybe all it means
is that we need is an additional `clobbers-match-data`, which means that
the contents of the match-data can't be relied upon after the call).

> More fine-grained effects could be added, such as throws, mutation of
> arguments, reading data referenced by arguments, etc.

If we ever want to be able to detect match-data errors via static
analysis, we'd need to know which functions set the match data, which
functions are guaranteed not to affect the match-data, and which
functions read the match data (then we can warn any time you read the
match data even though you called a function not known to preserve the
match-data since the last call to a match-data-setting function).
Now admittedly, "preserve the match-data" is not really an effect ;-)

> It all depends on what is useful for the compiler(s) and related tools.

Indeed, we should keep things as simple as possible.  For me the main
benefit is that it seems easier to explain those effects than to explain
what it means to be "pure" or "side-effect-free", probably because both
of those terms already exist in computer-English but with not 100%
precise meanings and that our use doesn't match 100% either.


        Stefan

Re: master 0cbcc62: 'assoc' is not side-effect-free; constprop its pure subset

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Perhaps it was a mistake to add the TESTFN argument to assoc.
Maybe we should eliminate it and create another function which accepts
additional arguments.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)