[Top][All Lists]

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

Re: Saving match data

From: Philipp Stephani
Subject: Re: Saving match data
Date: Fri, 16 Jun 2017 19:24:01 +0000

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. 

reply via email to

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