From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27659: 26.0.50; Add string-matched-text: string-match + match-string Date: Sun, 23 Jul 2017 20:45:34 +0000 Message-ID: References: <87fue2rxm1.fsf@calancha-pc> <87mv7x451o.fsf@drachen> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c033d6aa09000555022e1e" X-Trace: blaine.gmane.org 1500842869 27258 195.159.176.226 (23 Jul 2017 20:47:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Jul 2017 20:47:49 +0000 (UTC) Cc: 27659@debbugs.gnu.org, Tino Calancha To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 23 22:47:45 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dZNmw-0006jx-I7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Jul 2017 22:47:42 +0200 Original-Received: from localhost ([::1]:51550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZNn2-00084Q-AZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Jul 2017 16:47:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZNlN-0006uD-7Y for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2017 16:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dZNlK-0000NY-0o for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2017 16:46:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dZNlJ-0000NQ-Sn for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2017 16:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dZNlJ-0005KO-Ll for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2017 16:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jul 2017 20:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27659 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 27659-submit@debbugs.gnu.org id=B27659.150084275120464 (code B ref 27659); Sun, 23 Jul 2017 20:46:01 +0000 Original-Received: (at 27659) by debbugs.gnu.org; 23 Jul 2017 20:45:51 +0000 Original-Received: from localhost ([127.0.0.1]:53659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dZNl9-0005Jz-7Q for submit@debbugs.gnu.org; Sun, 23 Jul 2017 16:45:51 -0400 Original-Received: from mail-oi0-f52.google.com ([209.85.218.52]:34549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dZNl8-0005Jo-6U for 27659@debbugs.gnu.org; Sun, 23 Jul 2017 16:45:50 -0400 Original-Received: by mail-oi0-f52.google.com with SMTP id x3so6858037oia.1 for <27659@debbugs.gnu.org>; Sun, 23 Jul 2017 13:45:50 -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 :cc; bh=JgvSHNj2ryNKYuHEnp+8/2CI7xf15WTsPXIfypu0YdE=; b=uV06H3eWwUFjRX/IBpHjmTNG17bSLAMlX3U7xBemCFjZpP+TJx23cdZWEASbS3MEFr fnjtuWIchnhMcS/7000UcZM2F0iZrM+PFp7fJrBJzMNGgReUqNCKxFSMdp9CUKWHkZXo tu6pqzkEE8ArR25uNHxtpbv5c6Aj5brfA12ekSwal0X/011kzlKcTRpM87MXZX6H6/Sb qzEmjlbLz6HNy190F7oeBvGWijsaN3MMZBBrq2qIvJeLb7JUei2UqkcHvWeqFZ/VKEXX E31zVEfyw5oHRrnCwvquUJTt4LoMWbCMC1duDLOadlwNueHGvkwTJMkL9ErCNUpEZzE3 GzQA== 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:cc; bh=JgvSHNj2ryNKYuHEnp+8/2CI7xf15WTsPXIfypu0YdE=; b=eih6egxZ6mBF7SpwL3DgXjbAVwrjxeR3gyf6NKp2dei5ZwGcUimsAiefNMuC/4zIU9 0u3PvLZcwM2qnTaO4kLMqMI55UPph+0HR9o8IDuPyWfj+JCUF7csPAe5ano5cHPyXRlX f/E+N48iSFZd355d35Lrs4o1If6F3PxFsHL/zsMX0Fg05n6Yt2N4yUPqkLjxjNdBpQD+ 6/xo37uquFpdJHrdN2/clIl3Sm/bkVSwiKK5C3P7+iqhfBTYTblCP1TBt0YFn9n4IJmR fg9bV7CUzRxqbPor9derTmdXyAM7I67aXJBPYlV8L2vyX8emfncO9Te/dw9dl7q+x+F0 wGnA== X-Gm-Message-State: AIVw11192/QIIdgFca91MYXwcjqfUNFNv8prWTlJRgw3AgYPjphsbsbI 8GqQlYNkxtUyTbeG6HXrdrocyIRI2Q== X-Received: by 10.202.4.208 with SMTP id 199mr5546614oie.182.1500842744740; Sun, 23 Jul 2017 13:45:44 -0700 (PDT) In-Reply-To: <87mv7x451o.fsf@drachen> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:134895 Archived-At: --001a11c033d6aa09000555022e1e Content-Type: text/plain; charset="UTF-8" Michael Heerdegen schrieb am Sa., 22. Juli 2017 um 03:46 Uhr: > Hi Philipp, > > nice idea! I have some questions: > > > +(pcase-defmacro rx (&rest regexps) > + "Build a `pcase' pattern matching `rx' regexps. > +The REGEXPS are interpreted as by `rx'. > > Should we tell what the semantics of multiple REGEXPS is? I guess they > are implicitly wrapped inside rx-`and' (but FWIW, the doc of `rx' also > fails to tell that). > yes, probably something should be added to the docstring of `rx'. > > > +Within the case code, the match data is bound as usual, but you > > This makes it sound like match data is bound pcase-branch-locally. > This isn't the case, right? > Yes, I've reworded it to sound less like a variable binding. > > > +In addition to the usual `rx' constructs, REGEXPS can contain the > +following constructs: > + > + (let VAR FORM...) creates a new explicitly numbered submatch > + that matches FORM and binds the match to > + VAR. > > This made me wonder what FORM should be. I think it means any rx > symbolic expression, so the name FORM seems misleading. > I think the words `form' and `sexp' are used mostly interchangeably nowadays, and the docstring of `rx' speaks of "forms" several times. > > > +(ert-deftest pcase-tests-rx () > + (should (equal (pcase "a 1 2 3 1 b" > + ((rx (let u (+ digit)) space > + (let v (+ digit)) space > + (let v (+ digit)) space > + (backref-var u)) > + (list u v))) > + '("1" "3")))) > + > > I don't understand the example (or test). Is v first bound to 2, and > after that rebound to 3? This seems at least surprising, since let > behaves differently in pcase, e.g. > > (pcase 'foo > ((and (let x 1) (let x 2)) x)) > ==> nil > > Hmm, in general I see the risk of confusing this `let' with `pcase' let. > It seems to be something very different. Maybe you could just pick a > different name, `bind' maybe? > > > I'd rather stick with the short and common `let'. That there's a name clash is unfortunate, but there are lots of similar cases (e.g. pcase `let' vs. Lisp `let', rx `and' and `or'). --001a11c033d6aa09000555022e1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am Sa., 22. Juli 2017 um 03:46=C2=A0Uhr:
Hi Philipp,

nice idea!=C2=A0 I have some questions:


+(pcase-defmacro rx (&rest regexps)
+=C2=A0 "Build a `pcase' pattern matching `rx' regexps.
+The REGEXPS are interpreted as by `rx'.

Should we tell what the semantics of multiple REGEXPS is?=C2=A0 I guess the= y
are implicitly wrapped inside rx-`and' (but FWIW, the doc of `rx' a= lso
fails to tell that).


yes= , probably something should be added to the docstring of `rx'.
=C2=A0


+Within the case code, the match data is bound as usual, but you

This makes it sound like match data is bound pcase-branch-locally.
This isn't the case, right?

Yes, I&= #39;ve reworded it to sound less like a variable binding.
=C2=A0<= /div>


+In addition to the usual `rx' constructs, REGEXPS can contain the
+following constructs:
+
+=C2=A0 (let VAR FORM...)=C2=A0 creates a new explicitly numbered submatch<= br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0that matches FORM and binds the match to
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0VAR.

This made me wonder what FORM should be.=C2=A0 I think it means any rx
symbolic expression, so the name FORM seems misleading.

I think the words `form' and `sexp' are used mostl= y interchangeably nowadays, and the docstring of `rx' speaks of "f= orms" several times.
=C2=A0


+(ert-deftest pcase-tests-rx ()
+=C2=A0 (should (equal (pcase "a 1 2 3 1 b"
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((rx = (let u (+ digit)) space
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (let v (+ digit)) space
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (let v (+ digit)) space
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (backref-var u))
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (lis= t u v)))
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'("= 1" "3"))))
+

I don't understand the example (or test).=C2=A0 Is v first bound to 2, = and
after that rebound to 3?=C2=A0 This seems at least surprising, since let behaves differently in pcase, e.g.

(pcase 'foo
=C2=A0 ((and (let x 1) (let x 2)) x))
=3D=3D> nil

Hmm, in general I see the risk of confusing this `let' with `pcase'= let.
It seems to be something very different.=C2=A0 Maybe you could just pick a<= br> different name, `bind' maybe?



I'd rather stick with the short an= d common `let'. That there's a name clash is unfortunate, but there= are lots of similar cases (e.g. pcase `let' vs. Lisp `let', rx `an= d' and `or').
--001a11c033d6aa09000555022e1e--