I don't know Regex (ideasof.andersaberg.com)

Actually, I like neither. The code is easier to read, but the regex gives a broader overview. This is something where parser combinators can shine. E.g., from Haskell's email-validate:

  addrSpec = do
  	localPart <- local
  	char '@'
  	domainPart <- domain
  	endOfInput
  	return (EmailAddress localPart domainPart)

To end with a positive note: good work on the library! I think it will be useful for many people who dislike writing regexes.

For more see http://en.wikipedia.org/wiki/Email_address#Valid_email_addre...

    ^ ( [a-z0-9]+ @ [a-z]+ \. [a-z]+ ) $

https://news.ycombinator.com/item?id=6164276

For example, it showed that the horrible email regex in this article had a couple of errors - the dot before the TLD should be escaped (without the escape, it's 'any character'), and that group #1 can either be letters or digits, but not both (when it can be).

It's still not a good regex, since there are characters like hyphens, dots, and pluses that are valid pre-'@' characters, which both sample regexes fail to recognise.

    .Exactly(1).Of(".")

    (.{1,1})

    pat = re.compile(r'^ \w+ @ [A-Za-z]\w*  \. \w+ $', re.X)
    if pat.match('r@acnt.me'):
        print "woot"

    pat = re.compile(r'''^ \w+  # rahul
                    @
                    [A-Za-z]\w*  # thoughtnirvana
                    \.
                    \w+ # com
                    $''',
                    re.X)

  var regEx = {(?:^)[A-Za-z]([A-Za-z]+|(?:\d+))(@{1,1})[A-Za-z]+(.{1,1})[A-Za-z]+(?:$)}

([A-Za-z]+|(?:\d+)) - What's going on here? You have a capturing group and within that capturing group, you have the or part marked as non capturing. What's the intent?

(@{1,1}) - @{1,1} is the same as @. Also, why are you capturing it? I think you are using parens for making the regex readable. You should use the IgnorePatternWhitespace instead http://msdn.microsoft.com/en-us/library/yd1hzczs.aspx

  var letter = "[a-zA-Z]";
  var letters = letter + "+";
  ...

  var regEx = letter ++
    letters ++
    "|" ++ ...

I also tested my understanding afterwards with some online exercises chosen from these lists:

http://www.emacs.uniyar.ac.ru/doc/em24h/emacs081.htm

http://blogs.msdn.com/ericgu/archive/category/11323.aspx

This reference was handy while doing the exercises: http://www.regular-expressions.info/reference.html

Knowing regexes has been very helpful to me in general. I have used regexes in reformatting my code through find and replace, in finding the code that I need to edit next or that could be causing a certain problem, in writing Apache config URL rewriting rules, in writing poor man’s language parsers that assisted me in generating code, in converting raw data into programming language literals, in understanding user input validation rules, and in other ways. I think that any serious developer who expects to work with more than one programming language in their lifetime should understand regular expressions. Thus, I encourage the OP to try learning regexes, using the resources linked above.

That said, I agree that regexes could be easier to understand. I rather wish that Perl 6’s revised, simpler regex syntax (http://perlcabal.org/syn/S05.html) were the universal standard.

If you use regexes a lot, and get mentally strained by the complexity of some of your bigger ones, consider learning about parsers too, another type of tool that lets you manipulate text in more powerful ways, with longer but more readable code than regexes. http://kschiess.github.io/parslet/ is a simple parsing library to start with if you use Ruby. In fact, Parslet is rather like a more powerful and more theoretically-sound version of the OP’s library RegExpBuilder. Like RegExpBuilder, Parslet uses chains of methods with English names to build parsers.

An example: What are .Letters()? [a-zA-Z]? Are diacritics included? The whole UTF-8 letter range?

And suddenly, you have to specify that character soup and the example goes to hell, because it reintroduces most of complexities in the original regexp.

https://github.com/VerbalExpressions

Tools like sed and regexes are compact and very powerful, and they aren't difficult to learn. I really don't understand the need for this library, which seem needlessly verbose. And you will still need to be able to read regexes in other people's code.

It's a nice idea, and good work, but in my opinion it's solving a problem that doesn't exist.

http://regex.learncodethehardway.org/book/

The original repository is at:

https://github.com/thebinarysearchtree/RegExpBuilder

I came up with this idea 2 years ago. Some differences I see between my idea and this c# implementation are:

Or() is confusing by itself. In mine, you pass in objects or strings, such as:

   var regex = new RegExpBuilder()
     .either(pattern1)
     .or(pattern2);

   var regex = new RegExpBuilder()
     .either("sometime")
     .or("soon")
     .or("never");

There are shortcuts - you don't have to do

   .exactly(1).of("hackernews")

   .then("hackernews");

This tool just hindering your progression and yet another abstraction someone has to to learn if they are going to deal with this code. It would make sense if this was a one-off thing and you'd be saving someone the effort of learning some weird protocol or syntax, but since regex is so common and most programmers have just learned to deal with them, you're actually adding more cognitive load, since now they have to know two things instead of one. Imagine coming across this in someone else's code and discovering the regex didn't work as expected. Now I have to debug the regex and figure out whether it's a bug in the tool, or in my regex, etc…

http://www.arachnoid.com/regex_lab/

Philosophically, there are two approaches to making regexes an effective tool -- expand regex syntax until it's so verbose that there's no possibility for confusion -- ironically a somewhat confusing tactic as this topic's comments demonstrate -- or learn native regex in an interactive way that shows its effect on example text, until you develop an instinct for it. I prefer the latter.

It's like learning music by keyboard -- shall we paint each keyboard key a different color and recode sheet music to agree, or shall we use a teaching method that makes the keyboard gradually seem more natural?

Here is the articles example converted to Rebol's parse dialect (minus capturing but it's easy to add):

  ; build some prereqs for parse
  num:         charset [#"0" - #"9"]
  alpha-lower: charset [#"a" - #"z"]
  alpha-upper: charset [#"A" - #"Z"]
  alpha:       union alpha-lower alpha-upper
  alpha-num:   union alpha num 

  ; create parse rule block
  simple-email-rule: [
      alpha
      any alpha-num
      #"@"
      some alpha-num
      #"."
      some alpha-num
      end 
  ]

  ;
  ; then later...

  parse "valid@example.com" simple-email-rule  ; => true
  parse "notanemailaddress" simple-email-rule  ; => false

Of course the regex is simpler as everyone who knows regexes will understand it.

If you don't know regex you should invest time on learning it. It's the same if you say:

    I don't know german, look at this german sentence builder, it's so much nicer!
    > builder.firstPersonPronom().verb("like").directObject(new SecondPersonPronom());
    > => "Ich mag dich"