[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: regular expressions


concatenating regular expressions
>  > NG validator; it is only 70 lines of code in Scheme, after all. Proved
>  > to be very useful for debugging.
> 
> Very clever. But a naive implementation would just recursively 
> concatenate the strings to make a single regex strings. Could you 
> elaborate on the debugging advantage, i.e., how it makes it easier for a 
> schema writer to debug regular expressions?

An implementation that 'just' concatenates strings  is not naive, it is 
right. And this right implementation aids debugging because it makes
regular expressions much more readable -- it is the experience, not a
hypothesis.

It makes a regular expression orthogonal: if there are repeating pieces,
one has to edit a piece only once, instead of four times as in the original
example.

Besides, "just" concatenating strings is the right thing because it reveals
non-regular grammars immediately through endless recursion; thus assuring
that regular expressions remain regular.

In few words: it makes regex debugging easier, because it allows to understand
what you wrote at a previous attempt and fix bugs as many times as there are bugs,
not as many times as the same bugs are repeated through cut and paste.

> Jeni Tennison used the same idea with a slightly different syntax in her 
> DTLL proposal (I've lost the URL). Her idea had the added twist that an 
> application could receive the results of the regular expression parse as 
> a structured result, e.g., through a SAX API. Thus, using your example, 
> the string "(David Tolpen)David.Tolpin@n..." might produce the 
> 'infoset':
> 
> <start>
>    <comment>(David Tolpen)</comment>
>    <local-part>
>      <atoms>
>        <atom>David</atom>.<atom>Tolpin</atom>
>      </atoms>
>     </local-part>@<domain>
>      <atoms>
>        <atom>nospam</atom>.<atom>net</atom>
>      </atoms>
>     </domain>
> </start>

This is a powerful syntax, but  
- it is a different problem. What I am talking about is not a query language,
  but a validation rule.
- there are good tools that solve the problem of regular parsing, such as lex(1).
  adding XML output to them will do the above, but will still keep the problem
  of writing complex expressions for tokens intact.
- it is a bold objective, but it cannot be solved with current tools; breaking
  a regex into named pieces can be implemented immediately and will make the life
  more fun.

David



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.