From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Clarify `pcase' `rx' pattern doc Date: Sat, 07 Jul 2018 16:57:50 +0300 Message-ID: <83va9ri1wh.fsf@gnu.org> References: <87fu1rqr6m.fsf@web.de> <87in6gff2t.fsf@web.de> <83wouwrq3d.fsf@gnu.org> <87tvpw4cjt.fsf@web.de> <83vaacqjpl.fsf@gnu.org> <87lgb841g0.fsf@web.de> <831scxvd5a.fsf@gnu.org> <87bmbk4586.fsf@web.de> <834lhbleol.fsf@gnu.org> <8736wvf9rv.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530971779 21115 195.159.176.226 (7 Jul 2018 13:56:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jul 2018 13:56:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 07 15:56:15 2018 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 1fbnh6-0005Ln-VY for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2018 15:56:13 +0200 Original-Received: from localhost ([::1]:33796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbnjE-0005Mn-8R for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2018 09:58:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbnig-0005Mg-J5 for emacs-devel@gnu.org; Sat, 07 Jul 2018 09:57:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbnid-0001mv-Gd for emacs-devel@gnu.org; Sat, 07 Jul 2018 09:57:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbnid-0001mj-CR; Sat, 07 Jul 2018 09:57:47 -0400 Original-Received: from [176.228.60.248] (port=2489 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fbnic-0005CT-Lk; Sat, 07 Jul 2018 09:57:47 -0400 In-reply-to: <8736wvf9rv.fsf@web.de> (message from Michael Heerdegen on Sat, 07 Jul 2018 15:36:04 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:227058 Archived-At: > From: Michael Heerdegen > Cc: emacs-devel@gnu.org > Date: Sat, 07 Jul 2018 15:36:04 +0200 > > Eli Zaretskii writes: > > > > > + [...] If the target is not a string, signal an error. > > > > > > We want to change that, so I think you can drop that sentence. > > > > Shouldn't it be dropped when that change is committed? > > Then we would break documented behavior then. What would be the gain? Sorry, I must be confused about this. You said "we want to change that", so I interpreted that to mean that such a change was not yet done and will be done shortly. IMO, changes in documentation should be committed together with code changes that modify the behavior described in the documentation, thus my question. Did I misunderstand? If you fear that having this sentence in the doc string will somehow preclude us from making the code change, or make it harder, then the doc string already says that, so if there's a problem, it is already with us, no? > > > But can we remove the sentence saying "Multiple occurrences of the > > > same VAR refer to the same submatch."? It's completely redundant > > > IMHO. > > > > Is it redundant even when VAR is not a submatch number, but a symbol? > > I think so. A symbol VAR references the explicit binding created with > (let VAR ...), i.e. a submatch, just like in the number case. I'm just asking whether it will be immediately clear to users that any reference to VAR refers to the same submatch. I'm okay with removing it if you say so. > > Btw, in this part: > > > > > + (let VAR SEXP...) creates a new explicitly numbered submatch > > > + that matches regular expressions SEXP, and > > > + binds the match to VAR. > > > > Does "explicitly numbered" mean that VAR must be a number? If it can > > be something else, perhaps "explicitly named" is better? > > AFAIK, in `let' VAR must be a symbol, but it seems the submatch is also > numbered as side effect, e.g. > > (pcase "Hala" > ((rx "H" (let x "a") (regex ".*") (backref 1)) x)) > ==> "a" So you agree that "explicitly named" is a better wording? > In `backref' the argument can be a number or a symbol VAR. That's why I > would prefer a different argument name in the docstring, "REF" maybe. I > had done that in my suggested patch. I'm okay with using REF there.