bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Stefan Monnier]

> I don't think we can really do that, as that would allow the byte
> compiler to introduce bugs in the code, right? The manual states that
> "This function [concat] always constructs a new string that is not
> ‘eq’ to any existing string" so I don't see how it could ever be pure.

And yet, `concat` has been marked as "pure" even before we introduced
the notion of pure.  More specifically, the code in byte-opt.el which
optimizes calls to pure functions was originally written exclusively for
`concat`:

    commit 79d137ffe7dac5fe3041b4916c715f4ce91143af
    Author: Karl Heuer <kwzh@gnu.org>
    Date:   Mon Nov 3 03:58:23 1997 +0000
    
        (byte-optimize-concat): New function.

followed by:

    commit e856a453a1c1ce1907b3b582841bce3e9cff8cec
    Author: Stefan Monnier <monnier@iro.umontreal.ca>
    Date:   Mon Mar 22 15:21:08 2004 +0000
    
        (byte-compile-log-lap, byte-compile-inline-expand): Use backquote.
        (byte-optimize-pure-func): Rename from byte-optimize-concat.
        (symbol-name, regexp-opt, regexp-quote): Mark as pure.


-- Stefan