[jonaphin]

Wow. My mind is blown.

It almost feels like what high level programming languages are to assembly code.

Sure, we can (and should) learn Regex constructs, but it is undeniable that this library provides an unmatched level of clarity.

Kudos to Krain for coming up with such an elegant solution to the issue of Regex building/reading.

[draegtun]

Have a look at Rebol parse dialect for an alternative mind blowing way of doing things!

Here's is OP example ported to parse:

  ; build some sub rules
  r: context [
    domain: charset [#"a" - #"z" #"-"]
    proto:  ["http" | "https"]
    tld:    ["com" | "org"]
  ]
  
  ; simple URI rule
  rule: [
    copy proto r/proto
    "://"
    some [copy d some r/domain #"." (append domain d)]
    copy tld r/tld
    ["/" | end]
  ]
  
  ; capture
  proto: tld: d: none
  domain: []
  
  ; usage example
  parse "http://www.example.com/" rule

  ; Above returns true with following variables set to...
  ;
  ; proto  = "http"
  ; domain = ["www" "example"]
  ; tld    = "com"

Here's a nice tutorial on parse (though it's probably Rebol 2 centric) - http://www.codeconscious.com/rebol/parse-tutorial.html

[eCa]

Personally, I would not use this. One of the powers of regex is the similarity (depending on complexity and structure) between the regex pattern and what a matching string looks like. By doing it this way, a lot of noise is introduced that can make parsing more difficult.

I don't find:

    find { matching { [word, "-"] }.multiple }

Clearer than:

    ([\w\-]+)

It might be an alternative way introduce regexes though.

I would also like to see a more complex regex written this way.

[krainboltgreene]

In that example I wanted to show off a the matching and multiple syntax.

[krainboltgreene]

That's really too much praise, and I'm definitely not the first person to come up with this. See: Verbal Expressions and TextualRegex before that.