From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Saving match data Date: Fri, 16 Jun 2017 19:24:01 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c18d98ce303ec055218ba31" X-Trace: blaine.gmane.org 1497641095 4655 195.159.176.226 (16 Jun 2017 19:24:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Jun 2017 19:24:55 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 16 21:24:50 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwrS-0000uw-23 for ged-emacs-devel@m.gmane.org; Fri, 16 Jun 2017 21:24:50 +0200 Original-Received: from localhost ([::1]:60507 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLwrX-0000Yg-F6 for ged-emacs-devel@m.gmane.org; Fri, 16 Jun 2017 15:24:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLwqr-0000X8-Uj for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:24:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLwqq-0007lF-R5 for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:24:13 -0400 Original-Received: from mail-oi0-x22a.google.com ([2607:f8b0:4003:c06::22a]:32918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dLwqq-0007kh-Hm for emacs-devel@gnu.org; Fri, 16 Jun 2017 15:24:12 -0400 Original-Received: by mail-oi0-x22a.google.com with SMTP id s3so29231714oia.0 for ; Fri, 16 Jun 2017 12:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+dw1WgdJiDklZR+mw1Y1F63y974+LtRZhkWIqXcxTWo=; b=jbbZYc2WT6BLVYFQw4iVndQIW2JFkSx6YempDY8ylFhBMLpSGQnm/tD8GWaiGPBLT2 0mQMDGZbFY2/wqdtyFpPgHi6+txUsy/tGV8peDQmTVWedkntlIkkzb/LF1nWO+wGcENm PhGmkl1hMYK13Y2lks+uCwejDW7kc/FZhBEqgyND4yRfq4QNAEwYMG93VU0X0mcDo8Ex rxVGImeyT47K4WLKXdnp+07RhyKwPEPWYSJMhszN0IfJyaVAJ2tjVpV3qAYkQq1fV4Y5 m2+kF3RFzS6DmsNhXPpmp8eun8kzZz8MGdTpAoIpg1d7I3C+bVOXVuA2CJYVhhebo8Fb vZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+dw1WgdJiDklZR+mw1Y1F63y974+LtRZhkWIqXcxTWo=; b=b0GxvaIMTJmsU3bApuRfZGjo4rxzkhcAjzZtGZDCRIvstZIT8aL7f/lA8Xw4TQJCyw UFr6r5/uG9EvnB9yQ8whWwNPuWWi2sJH+c0rWukjdANaa0UXOHJ/ebrESivZYipbfkvI C8X7ElUM2StqpNqaHVraQ4EcawLGCx7mvyMiRepA5LzptlcDoEqDl3V+kP71Lwk18sZW zdPHSZ2NKE6GkGS0MOk926GWmyy44P9NLPJ3YsAEkVuS7VibnKDOB6/0aET1kqBVkCIH 2sDMK0/t9CIvu9Vp+CXYOvd6v2F70IEUfmZ14NpjAUcAwqBfxIvbXrvNwiKTEIQP2usr jQOw== X-Gm-Message-State: AKS2vOyXFieatdzR/HnVwTSOAC4VUoP+LQ0juy0RhlInHggZjB+UbtKx c2H8N6a7QRw1Y5NFAa7R4I+Aw43TJA== X-Received: by 10.202.6.131 with SMTP id 125mr6245862oig.114.1497641051681; Fri, 16 Jun 2017 12:24:11 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215684 Archived-At: --94eb2c18d98ce303ec055218ba31 Content-Type: text/plain; charset="UTF-8" It's been a while, but I'm finally coming back to this. Stefan Monnier 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. --94eb2c18d98ce303ec055218ba31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's been a while, but I'm finally coming back to = this.

Stefan Monnier <= ;monnier@iro.umontreal.ca&g= t; schrieb am Mi., 28. Sep. 2016 um 18:12=C2=A0Uhr:
> I think this statement is surprising

Agreed.=C2=A0 That's why we have to write it explicitly in the doc ;-)<= br>

Could we also write it in the docstring= s of the match-related functions (match-beginning etc.)? I guess people are= more likely to read those than the manual.
=C2=A0

> and puts unnecessary burden on Elisp programmers.

Experience shows that it's the more efficient choice, tho: both in term= s
of CPU efficiency and in terms of programmer efficiency.


I disagree, but it's probably too late to change = the contract now.
=C2=A0

> 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.=C2=A0 It would be good to document it, tho it will take some wo= rk
to clarify what is meant by "primitive".
At least all functions that are side-effect-free or pure (in th= e sense of byte-opt) are trivially in this category, so we could amend the = help texts of these functions automatically.
(Looking at that lis= t, I'm wondering why so few functions are marked as pure - e.g. even `e= q' is apparently not pure?)
=C2=A0

> "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*.=C2=A0 It's an eno= rmous
amount of work, can't be automated,

Un= fortunately yes.
=C2=A0
and c= omes 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= 9;t modify global state any more.=C2=A0
--94eb2c18d98ce303ec055218ba31--