3 ms·

I don't always want to spend insane amounts of time writing full AST parsers. Sometimes it is a lot easier to write a simple, hacky, throwaway regex. It's a bit

I don't always want to spend insane amounts of time writing full AST parsers. Sometimes it is a lot easier to write a simple, hacky, throwaway regex. It's a bit much to claim that backtracking regular expressions, a very useful tool sometimes, should never ever be used and everybody should waste loads of time writing careful code even in situations where it isn't required. The problem is not the tool. The problem is using the tool for the wrong job - although who knows, maybe if they didn't just chuck out a quick hacky implementation, then atom simply wouldn't have the feature at all - in which case it is a trade-off between having the feature at all and an evidently tiny corner case bug that was easily fixed by someone who isn't even a regular developer of the project. So I don't see the reason to be outraged or judgemental here.

EGreg 11y ago
I don't often write AST parsers but when I do, I don't and write regexps instead.
jerf 11y ago
"I don't always want to spend insane amounts of time writing full AST parsers." This is an effect of the language, not the problem space. Backtracking REs make it very easy to write bad code, and then most languages make writing the parsing code hard. If you're in a language that makes parsing code easier, like Haskell, then the tradeoff isn't anywhere near so bad. I don't mention Haskell just because it's the trendy thingy, I mention it because parser combinators really do make for some very easy parsers, and while parser combinators can exist in other languages they tend to be very syntactically heavyweight. Perl 6 is supposed to make parsing perhaps even easier, but I haven't played with it to know. Parsing isn't really that hard, it just plays very poorly with Algol-inspired syntax. To be clear, since this is the Internet and the presumption of disagreement is strong, this post is not an explanation of why you're wrong... it's an explanation of why you're right. It is absolutely a true statement that in most languages you're way better off bashing out a dangerous RE than writing a proper parser even for something as simple as this.
- rspeer 11y ago
  Haskell is, in fact, a really good way to write parser code. That's the main thing I use Haskell for. But how are you suggesting that Haskell could solve the problem of letting CoffeeScript plugins express which text they should apply to in a CoffeeScript text editor?
  - paulddraper 11y ago
    He's not suggesting that. He's suggesting that the correct solution (recursive descent parser) is not inherently hard, but CoffeeScript makes it hard enough that people reach for less good approaches.
- giovannibajo1 11y ago
  Interesting. Can you point to a piece of Haskell code that does some parsing of roughly the same level of complexity of that in the OP, so that we can compare how long it takes to write such a parser compared to a regex?
zeveb 11y ago
> I don't always want to spend insane amounts of time writing full AST parsers. Then don't use languages whose grammars require insane amounts of effort to parse. One can write a decent S-expression parser in an hour or two, and a full parser in a weekend. S-expressions can represent everything anyone ever needs to work with, so why use anything else?
emodendroket 11y ago
> Sometimes it is a lot easier to write a simple, hacky, throwaway regex. I mean, yes, but I'd argue that "I am writing software which will spend a significant amount of its time parsing code" is not one of the times when that is an appropriate instinct.

EGreg 11y ago

I don't often write AST parsers but when I do, I don't and write regexps instead.

jerf 11y ago

"I don't always want to spend insane amounts of time writing full AST parsers." This is an effect of the language, not the problem space. Backtracking REs make it very easy to write bad code, and then most languages make writing the parsing code hard. If you're in a language that makes parsing code easier, like Haskell, then the tradeoff isn't anywhere near so bad. I don't mention Haskell just because it's the trendy thingy, I mention it because parser combinators really do make for some very easy parsers, and while parser combinators can exist in other languages they tend to be very syntactically heavyweight. Perl 6 is supposed to make parsing perhaps even easier, but I haven't played with it to know. Parsing isn't really that hard, it just plays very poorly with Algol-inspired syntax. To be clear, since this is the Internet and the presumption of disagreement is strong, this post is not an explanation of why you're wrong... it's an explanation of why you're right. It is absolutely a true statement that in most languages you're way better off bashing out a dangerous RE than writing a proper parser even for something as simple as this.

rspeer 11y ago
Haskell is, in fact, a really good way to write parser code. That's the main thing I use Haskell for. But how are you suggesting that Haskell could solve the problem of letting CoffeeScript plugins express which text they should apply to in a CoffeeScript text editor?
- paulddraper 11y ago
  He's not suggesting that. He's suggesting that the correct solution (recursive descent parser) is not inherently hard, but CoffeeScript makes it hard enough that people reach for less good approaches.
giovannibajo1 11y ago
Interesting. Can you point to a piece of Haskell code that does some parsing of roughly the same level of complexity of that in the OP, so that we can compare how long it takes to write such a parser compared to a regex?

zeveb 11y ago

> I don't always want to spend insane amounts of time writing full AST parsers. Then don't use languages whose grammars require insane amounts of effort to parse. One can write a decent S-expression parser in an hour or two, and a full parser in a weekend. S-expressions can represent everything anyone ever needs to work with, so why use anything else?

emodendroket 11y ago

> Sometimes it is a lot easier to write a simple, hacky, throwaway regex. I mean, yes, but I'd argue that "I am writing software which will spend a significant amount of its time parsing code" is not one of the times when that is an appropriate instinct.