Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
References: <4E93664D.7090105@residenset.net> <7225.1318285652@cl.cam.ac.uk>
            <CANQYN6z5qgHti7AXdRh9r+C4S2pR=qu9cQGnDp+cr1xFcNTptA@mail.gmail.com> <4E945FF9.1060803@residenset.net>
            <CANQYN6yfd4MW9tmjJfOyyfsT1j-W18bUDnGvvBfN6-zpCsdv-g@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Message-ID:  <B5D03245-5C18-4AA9-9D56-8BD23A3687D2@gmail.com>
Date:         Thu, 13 Oct 2011 18:28:50 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: Strings, and regular expressions
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <CANQYN6yfd4MW9tmjJfOyyfsT1j-W18bUDnGvvBfN6-zpCsdv-g@mail.gmail.com>
Precedence: list
Status: R

On 12/10/2011, at 1:29 PM, Bruno Le Floch wrote:

> For short strings (e.g., matching \d\d\d\d-\d\d-\d\d on 2011-10-11),
> one third of the time is spent on building the automaton from the
> regular expression, and two thirds on running the automaton. I don't
> know how important that is in practice. Two aspects:
> 
>  - providing it requires more code --- true
> 
>  - the N arguments may be confusing (e.g., some people may think that
> it expects the regex as a string variable) --- not such a problem
> because the variable is checked to indeed be a proper compiled regex.
> 
> If the feeling is that it should go, then I'll remove that this weekend.

I think it would be premature to remove it at this stage. In fact, if you were going to remove either of them, it'd make more sense to me to remove the slower inline versions.

If you really thing the n/N distinction is confusing, what about a "currying" mechanism whereby regexes automatically create their prebuilt form and save it in an internal macro which is used for subsequent calls to the same regex?

-- Will