4 ms·

There are real benefits, they're called convenience and compatibility. And what's wrong with tying a language to a specific regex syntax? After all, you're als

by benniw 12y ago

There are real benefits, they're called convenience and compatibility. And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax. Regexes are also code, they just happens to be written in a different sub-language than the rest of the program.

coldtea 12y ago
>There are real benefits, they're called convenience and compatibility. Besides the fact that built-in regex literals are hardly any more "convenient" than a function call (a few keystrokes saved at best), regexes shouldn't be "convenient". If anything, they should be discouraged. To quote JWZ: "Some people, when confronted with a problem, think 'I know, I'll use regular expressions'. Now they have two problems." Oh, and "compatibility" doesn't come to play at all. Why would regex literals be any more "compatible" (with what?) than a regex object/functions? Compatible to what? JS and Ruby syntax? >And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax. For one, because you have to keep maintaining it forever, as part of the core syntax, whereas with a library you could deprecate it. It's not like there aren't several regex flavors, and approaches on how execute them (e.g: http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html ).
- benniw 12y ago
  Re "compatibility", I was thinking more about the language's library ecosystem, that could benefit from a single official regex implementation that can be relied upon and can be assumed to be known by programmers (when designing library APIs, for instance). But I actually forgot to mention the biggest benefit of having dedicated regex literals (rather than just passing them as strings to some constructor at run-time): They will be treated as part of the language, and can be parsed and compiled together with the rest of the code (a.k.a. at compile-time). Which means: 1) Better performance 2) Syntax errors in regexes are compile-time errors, which is a huge help in keeping bugs out 3) Editors will show you syntax highlighting inside of regexes It's hard to overstate the benefit of those three consequences; Once you've worked with a language that supports such compile-time regex literals (e.g. Perl) you don't want to go back to using regexes in a language that treats them as strings (e.g. Python). Regexes are code, and defining code in strings to be eval'ed at run-time is just plain wrong.

by benniw 12y ago

coldtea 12y ago

>There are real benefits, they're called convenience and compatibility. Besides the fact that built-in regex literals are hardly any more "convenient" than a function call (a few keystrokes saved at best), regexes shouldn't be "convenient". If anything, they should be discouraged. To quote JWZ: "Some people, when confronted with a problem, think 'I know, I'll use regular expressions'. Now they have two problems." Oh, and "compatibility" doesn't come to play at all. Why would regex literals be any more "compatible" (with what?) than a regex object/functions? Compatible to what? JS and Ruby syntax? >And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax. For one, because you have to keep maintaining it forever, as part of the core syntax, whereas with a library you could deprecate it. It's not like there aren't several regex flavors, and approaches on how execute them (e.g: http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html ).

benniw 12y ago
Re "compatibility", I was thinking more about the language's library ecosystem, that could benefit from a single official regex implementation that can be relied upon and can be assumed to be known by programmers (when designing library APIs, for instance). But I actually forgot to mention the biggest benefit of having dedicated regex literals (rather than just passing them as strings to some constructor at run-time): They will be treated as part of the language, and can be parsed and compiled together with the rest of the code (a.k.a. at compile-time). Which means: 1) Better performance 2) Syntax errors in regexes are compile-time errors, which is a huge help in keeping bugs out 3) Editors will show you syntax highlighting inside of regexes It's hard to overstate the benefit of those three consequences; Once you've worked with a language that supports such compile-time regex literals (e.g. Perl) you don't want to go back to using regexes in a language that treats them as strings (e.g. Python). Regexes are code, and defining code in strings to be eval'ed at run-time is just plain wrong.