Warp wrote:
> are you suggesting that the reason for that *is* because
> they don't know how to (in contrast to this C preprocessor issue,

No, that I put down to laziness. ;-) The .NET regexp engine support 
backreferences (i.e., non-regular regexps), which you can't do without 
backtracking. I was simply surprised they put in enough effort to turn an 
"interpreted" regexp into a compiled regexp without special-casing the 
presumably common case of not having back-references.

Maybe I'm wrong and simply being able to extract groups is enough to require 
backtracking, and MS looked and saw the number of regexps that didn't 
extract groups but had this sort of behavior was low enough not to bother.

I imagine this may be also "economic" reasons in that they didn't have time 
to do a better job or something? Dunno.

That's why I was surprised.  FWIW, I'm also surprised that the token parsing 
is broken. I'm less surprised they don't *fix* it, is all. I mean, hell, *I* 
can think of trivial ways to fix it - just put a space around each argument 
you substitute in, unless it's with a # or ## operator.

>   Whatever the reason for either one of these two things might be,
> my suspicion is that the reason is primarily laziness in both cases:

Well, I'm guessing "laziness" of the original implementors in the first 
case. I'm guessing it's not "laziness" for *fixing* the tokenizer, and more 
"well enough" at this point.

I.e., I don't think reported bugs get left in because they're too lazy to 
fix it. Not enough economic incentive, maybe, which you might equate to 
"laziness" in your terminology, but which I'd call "not worth fixing" 
instead. But an active decision not to fix isn't what I'd call "lazy". But 
that might just be a terminology issue.

Whereas the regexp thing, I don't think that decision was likely made after 
the code was already released. It might have been "we don't have time" or 
"we don't think it'll help enough people" or even "if I bring it up, I'll 
wind up having to do it", all of which I'd classify as "lazy". But I think a 
manager telling the programmer not to program something isn't "laziness".

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message