User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929
            Thunderbird/7.0.1
MIME-Version: 1.0
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>
            <B5D03245-5C18-4AA9-9D56-8BD23A3687D2@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E969C01.2010604@morningstar2.co.uk>
Date:         Thu, 13 Oct 2011 09:06:25 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Strings, and regular expressions
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <B5D03245-5C18-4AA9-9D56-8BD23A3687D2@gmail.com>
Precedence: list
Status: R

On 13/10/2011 08:58, Will Robertson wrote:
> 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?

AS you say, I don't think removing stuff is the right way forward at
this point. The reason for raising this was to be clear that the current
approach is the best one. Having a set of n/N functions does seem to
require quite a lot of variants in the documentation, so I wanted to be
clear that this is best.

As Will says, an alternative is simply to save all regexes
automatically, and check for the existence of the regex before building
it. That of course costs in terms of macros, so the question is how many
regexes are likely to be used. (We are talking about a typesetting
system, so really this should not normally be 100s.)

On the other hand, perhaps the distinction is fine, and I'm worrying too
much.
-- 
Joseph Wright