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>
            <4E969C01.2010604@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6zanXoXbra+jFqnQjX3Gu9r-rJY4VQ1R=ctK+pfR11+HQ@mail.gmail.com>
Date:         Thu, 13 Oct 2011 05:40:49 -0400
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Strings, and regular expressions
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4E969C01.2010604@morningstar2.co.uk>
Precedence: list
Status: R

>> 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.)

You guys are right. I'll add this automatic storage this weekend, and
remove the N variants (since they will be done automatically).

--
Bruno