It's been a while, but I'm finally coming back to this.
Stefan Monnier <
address@hidden> schrieb am Mi., 28. Sep. 2016 um 18:12 Uhr:
> I think this statement is surprising
Agreed. That's why we have to write it explicitly in the doc ;-)
Could we also write it in the docstrings of the match-related functions (match-beginning etc.)? I guess people are more likely to read those than the manual.
> and puts unnecessary burden on Elisp programmers.
Experience shows that it's the more efficient choice, tho: both in terms
of CPU efficiency and in terms of programmer efficiency.
I disagree, but it's probably too late to change the contract now.
> Taken literally, Elisp programmers need to surround even calls to
> `car' with `save-match-data' because the documentation of `car'
> doesn't specify that it doesn't change the match data.
Indeed, there's also an expectation that "primitives" don't touch the
match-data. It would be good to document it, tho it will take some work
to clarify what is meant by "primitive".
At least all functions that are side-effect-free or pure (in the sense of byte-opt) are trivially in this category, so we could amend the help texts of these functions automatically.
(Looking at that list, I'm wondering why so few functions are marked as pure - e.g. even `eq' is apparently not pure?)
> "Notice that no functions are allowed to overwrite the match data unless
> they're explicitly documented to do so."
> and then clean up existing documentation and add `save-match-data' where
> appropriate.
That would imply adding save-match-data *everywhere*. It's an enormous
amount of work, can't be automated,
Unfortunately yes.
and comes with only two obvious results:
- our Elisp source code will be significantly larger.
- Emacs will be slower.
It would also come with the obvious result of making the Emacs function contracts much clearer because they wouldn't modify global state any more.