Re: pure-fns in byte-opt.el

[Clément Pit-Claudel]

On 2017-07-26 02:08, Stefan Monnier wrote:
>>> If string-to-char were a pure function, it would return the same
>>> value in both calls (since the arguments are `eq')
>>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> What do you mean by this?
> 
> That the argument passed to the first call is `eq` with the argument
> passed to the second call.

I see.  That's not what I understood to be usually meant by "pure": although 
both arguments are pointers to the same address in memory, the contents of that 
address have been modified in the meantime.  In that sense, haven't the two 
calls to string-to-char been passed different values (albeit stored in the same 
memory location)?

In other words, I don't see your example as proving that string-to-char is 
impure; instead, it just looks like a pure function that's passed two different 
values.  As a concrete example, is the following a proof that string-to-syntax 
is impure? If so, it should be removed from our list of pure functions :)

  (let ((s (make-string 1 ?w)))
    (list (string-to-syntax s)
          (progn
            (aset s 0 ?_)
            (string-to-syntax s))))

The same argument seems to apply to *all* functions marked pure in byte-opt.el, 
except `symbol-name' (namely `concat', `regexp-opt', `regexp-quote', and 
`string-to-syntax'). Under your definition, neither the `length' nor the `car' 
function on lists are pure. In fact, if I understand it correctly, your 
definition seems to imply that any function that reads mutable data is (by 
definition) impure.  Is that right?  This seems very restrictive, and it seems 
to be contradicted by existing 'pure' annotations in our codebase.  How do we 
call the property shared by `concat', `length', and `string-to-chars'? in ELisp 
land, if it's not "pure"?

In byte-opt we say this:

;; pure functions are side-effect free functions whose values depend
;; only on their arguments. For these functions, calls with constant
;; arguments can be evaluated at compile time. This may shift run time
;; errors to compile time.

I tried to get inspiration from looking at other `pure' annotations in lisp/ 
but the examples I found were confusing.  All four examples of (pure t) 
functions in smie.el take lists as input, for example:

(defun smie-precs->prec2 (precs)
  "Compute a 2D precedence table from a list of precedences. …
  (declare (pure t))

and indeed:

  (let ((s '((left "+") (right "*"))))
    (list (smie-precs->prec2 s)
          (progn
            (setf (caar s) 'right)
            (smie-precs->prec2 s))))

Can you point out where I went wrong? To me it just looks like Mark ran into a 
bug.

Clément.