unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: emacs-devel@gnu.org
Subject: Re: Clarify `pcase' `rx' pattern doc
Date: Sat, 07 Jul 2018 16:57:50 +0300	[thread overview]
Message-ID: <83va9ri1wh.fsf@gnu.org> (raw)
In-Reply-To: <8736wvf9rv.fsf@web.de> (message from Michael Heerdegen on Sat, 07 Jul 2018 15:36:04 +0200)

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 07 Jul 2018 15:36:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.



  reply	other threads:[~2018-07-07 13:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13  3:52 Clarify `pcase' `rx' pattern doc Michael Heerdegen
2018-06-13  5:43 ` Michael Heerdegen
2018-06-13  7:33   ` Andreas Schwab
2018-06-13  7:59     ` Michael Heerdegen
2018-06-13  8:18       ` Michael Heerdegen
2018-06-13 12:29         ` Yuri Khan
2018-06-18 12:34 ` Michael Heerdegen
2018-06-18 14:11   ` Stefan Monnier
2018-06-18 14:58     ` Michael Heerdegen
2018-06-18 16:56   ` Eli Zaretskii
2018-06-18 17:22     ` Michael Heerdegen
2018-06-18 17:55       ` Eli Zaretskii
2018-06-21 11:13     ` Michael Heerdegen
2018-06-21 14:48       ` Eli Zaretskii
2018-06-21 15:13         ` Michael Heerdegen
2018-06-23 13:35           ` Eli Zaretskii
2018-07-06 17:57             ` Michael Heerdegen
2018-07-07  6:53               ` Eli Zaretskii
2018-07-07 13:36                 ` Michael Heerdegen
2018-07-07 13:57                   ` Eli Zaretskii [this message]
2018-07-07 14:35                     ` Michael Heerdegen
2018-07-20  8:45                       ` Eli Zaretskii
2018-07-20 22:56                         ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83va9ri1wh.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).