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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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