LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 13 Oct 2011 18:28:50 +1030
Content-Type:
text/plain
Parts/Attachments:
text/plain (21 lines)
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

ATOM RSS1 RSS2