3 ms·
case /\(.+)!(.+)@(.+)/ nick, user, host = $1, $2, $3 ... vs if( (match=new Regex("(.+)!(.+)@(.+)").Match(caseInput)).Success ) {
by MaulingMonkey 13y ago
case /\(.+)!(.+)@(.+)/
nick, user, host = $1, $2, $3
...
vs
if( (match=new Regex("(.+)!(.+)@(.+)").Match(caseInput)).Success )
{
var nick = match.Groups[1].Value;
var user = match.Groups[2].Value;
var host = match.Groups[3].Value;
...
}
If I'm using a ton of regexps, having domain specific language support can certainly help keep things simpler and clearer, aiding usability by aiding readability. This is important enough people can and will resort to implementing their own domain specific languages. While I'm all for erring on the side of general purpose language features for a general purpose language, if only to reduce the possible explosion of corner cases for language design mistakes, discounting language level support as "inelegant" and having no benefits is, to me, tantamount to discounting DSLs in general for the same.
And perhaps you do so, but the argument doesn't resonate with me.
- MichaelGG 13y agoF# active patterns allow you to do exactly this kind of thing, in a general and extensive way, without building support for regex into the compiler. That's what I'm talking about. And it takes all of 4 lines to add the support: let (|Regex|_|) pattern input = let m = Regex.Match(input, pattern) if m.Success then Some(List.tail [ for g in m.Groups -> g.Value ]) else None Boom, done. I'd call that a far more elegant approach than hardcoding regex into the language. Edit: And nothing is stopping the core developers from including such patterns in the standard library. So you get the best of both worlds, a common well-known manner, and a useful general purpose feature that people can extend and use if they need so. Usage looks like: match phone with | Regex @"\(([0-9]{3})\)[-. ]?([0-9]{3})[-. ]?([0-9]{4})" [ area; prefix; suffix ] -> ... http://fssnip.net/29 http://fssnip.net/29