bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Andrea Corallo
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Wed, 08 Jul 2020 22:19:32 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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

> Hello Andrea,
>
>> In my version I assumed (after a look to the manual) to have strings to
>> be immutable only at speed 3.  Is it safe to assume this always instead?
>
> Ultimately it depends on the transformations you do, but yes: this
> patch substitutes let-bound names for their values, and since the
> behaviour of mutating string literals is undefined, it's
> safe. Consider:
>
> (let ((s "abc"))
>   (f s)
>   s)
>
> It doesn't matter what 'f' does; since it isn't permitted to mutate its 
> argument string, the transformation to
>
> (progn (f "abc") "abc")
>
> is safe (assuming lexical binding, since f could otherwise set s to something 
> else).

Understand, in your code this predicate is used for substitution
therefore is just correct to substitute with the original object.

In mine is governating the objects we can materialize with const folding
so I had it a little stricter.  But this raise to me another doubt on
the topic that is: why don't we have the same in the byte-compiler?
That is:

(defun foo (x)
  (concat "bar" "foo"))

is byte compiled optimizing on `concat' because pure.  But doing that
the resulting string "barfoo" becomes immutable.

I'd expect "barfoo" to be mutable because without optimizations the
allocation would be done in the run-time.  In general how I imagined the
thing is that we can optimize only pure functions returning immutable
objects to avoid the risk of unexpectedly creating objects that should
not be changed.

Or is it maybe that the only way to certainly have a mutable string is
with `copy-sequence' or `make-string'?

>> Also I wanted ask why symbols are not included but only keywords, is
>> this to respect the side effect of interning them or something else?
>
> Symbols are included, but since this is (normalised) Lisp source,
> plain symbols are variables; constants of symbol type are represented
> as (quote SYM), matched by the and-expression. Keywords are just
> symbols whose name begin with a colon, like :chocolate, and need no
> quoting.

Understand

It's a little late hope I'm not talking stupid, thanks for your
patience.

  Andrea

-- 
akrl@sdf.org





reply via email to

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