User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; 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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E952E50.3020004@morningstar2.co.uk>
Date:         Wed, 12 Oct 2011 07:06:08 +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:  <CANQYN6yfd4MW9tmjJfOyyfsT1j-W18bUDnGvvBfN6-zpCsdv-g@mail.gmail.com>
Precedence: list
Status: R

On 12/10/2011 03:59, Bruno Le Floch wrote:
>> I'm not really clear/keen on the 'save the regex' stuff. The result
>> seems to be we have 'N' argument functions which need a pre-compiled
>> regex, and 'n' ones which need a normal regex. I don't really like this,
>> and am really not sure it's necessary to provide optimisation in this
>> way. In the absence of use cases, I'm not sure about needing this type
>> of additional complexity.
> 
> 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.

At this stage, I'm simply raising the issue and hoping others have some
input. For any reused regex, there will be a speed gain even for small
strings, I guess. Perhaps adding 'fast', 'precom' or 'prebuilt' to the
names would be sensible, as this will keep the speed gains but avoid
name ambiguity.

(On use cases, I guess most strings will be small. I can see regexs
useful for things like validating input such as numbers and dates. A
more complex application might be syntax highlighting in code samples,
but even then we should be looking at relatively small blocks.)

>> since
>>     \regex_split:nnN { (\w+) } { Hello,~world! } \l_result_seq
>> gives
>>     {} {Hello} {,~} {world} {!}
>> if I understand you correctly. Maybe all that is needed is an example in the
>> documentation.
> 
> I'll add \regex_extract_all:nnN this weekend.
> 
>> Rather than \regex_extract_once:nnN, I would probably call it
>> \regex_extract_first:nnN.
> 
> Not sure about that. We already have \tl_replace_(once|all):Nnn, which
> is what prompted me to use once there. @Joseph (and others), would
> \tl_replace_first:Nnn make more sense than _once?

For the moment, go with 'once', and we can discuss separately whether it
should be once/all or first/all in general. (We've only just changed
this from having 'in' in the name, which has caused confusion enough!)
--
Joseph Wright