Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Basically, preprocessor macro expansion should never create new tokens
> > unless the token pasting operator (##) is explicitly used to do so. However,
> > Microsoft's C preprocessor doesn't take this into account at all.

> I see. I can see where that would (A) really annoy and confuse people 
> expecting the standard behavior and (B) would really annoy people who relied 
> on it if it got changed. :-) All the more reason to make sure stuff works 
> before releasing it.

  I have really hard time believing that they aren't fixing it because they
don't want to break existing programs. I can't think of a rational situation
where you would *want* the buggy behavior of the preprocessor. It can only
be used for obfuscating code (for example, you don't expect something like
"-x" to really mean "--something_else"; that would be obfuscating beyond
belief).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   Basically, preprocessor macro expansion should never create new tokens
>>> unless the token pasting operator (##) is explicitly used to do so. However,
>>> Microsoft's C preprocessor doesn't take this into account at all.
> 
>> I see. I can see where that would (A) really annoy and confuse people 
>> expecting the standard behavior and (B) would really annoy people who relied 
>> on it if it got changed. :-) All the more reason to make sure stuff works 
>> before releasing it.
> 
>   I have really hard time believing that they aren't fixing it because they
> don't want to break existing programs. 

Well, there's always the possibility that they just don't find it 
economically worthwhile. But yeah, you'd be surprised at what existing 
programs rely on, bugwise. :-) I *don't* think it's because they can't 
figure out how to fix it. I think it's an intentional business decision, for 
whatever reason, not a "our compiler writer guys can't figure out how to fix 
this."

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   I have really hard time believing that they aren't fixing it because they
> > don't want to break existing programs. 

> Well, there's always the possibility that they just don't find it 
> economically worthwhile. But yeah, you'd be surprised at what existing 
> programs rely on, bugwise. :-) I *don't* think it's because they can't 
> figure out how to fix it. I think it's an intentional business decision, for 
> whatever reason, not a "our compiler writer guys can't figure out how to fix 
> this."

  Since this sidetrack started with you being surprised why compiled
regexps in .NET present exponential behavior (when it's possible to make
them linear-time), are you suggesting that the reason for that *is* because
they don't know how to (in contrast to this C preprocessor issue, which
might have economic reasons behind it rather than competence reasons)?

  Whatever the reason for either one of these two things might be,
my suspicion is that the reason is primarily laziness in both cases:
They could figure out how to do it properly, and they could implement it
properly, but they won't bother because it works "well enough" as it is
now. That's why I brought up this C preprocessor issue as an example.

-- 
                                                          - Warp

Post a reply to this message

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

> 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".

Reading several MS blogs it becomes obvious (if it wasn't already) that they 
have a limited amount of resource.  There are many things the developers 
would love to do, but they (or rather their managers) simply have to make a 
choice what to work on.  And of course they have to release software, 
because if they don't more people complain than if they release it with some 
feature not implemented or buggy.

Post a reply to this message

scott wrote:
> Reading several MS blogs it becomes obvious (if it wasn't already) that 
> they have a limited amount of resource. 

Yeah. I wouldn't call that "lazy" is all. :-)

The reason I was surprised at the regexp result was that they spent I'm sure 
a lot more time implementing a compiler for them than they would have 
implementing a better algorithm.

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

Post a reply to this message

> The reason I was surprised at the regexp result was that they spent I'm 
> sure a lot more time implementing a compiler for them than they would have 
> implementing a better algorithm.

I guess sometimes they just make mistakes or bad decisions like anyone else, 
and then it's not deemed worth it to spend the time going back and changing 
it.  That's just life, the only difference is when MS does it there's a lot 
of people who are affected!

Post a reply to this message

scott wrote:
>> The reason I was surprised at the regexp result was that they spent 
>> I'm sure a lot more time implementing a compiler for them than they 
>> would have implementing a better algorithm.
> 
> I guess sometimes they just make mistakes or bad decisions like anyone 
> else, and then it's not deemed worth it to spend the time going back and 
> changing it.  That's just life, the only difference is when MS does it 
> there's a lot of people who are affected!

Could be. Or whoever was assigned to implement it just looked at other 
peoples' implementations and dove in without really thinking it thru. It's 
pretty easy to get disaffected enough with a job that that sort of thing 
happens.  "Yeah, yeah, I'll get it written, get outa my face."

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

Post a reply to this message

Invisible wrote:
> "Syntactically JavaScript resembles Java with some influence from Perl,
> and features Perl-like regular expressions."
> 
> Since when does JS have regular expressions?

Like in Java, you can create a regular expression object with normal
object-creation syntax, using the RegExp class:

var regex = new RegExp("I( have|'ve) never seen ([^.,]*)");
var text = "I've never seen a system that can do that, but...";
return "he says he has never seen " + text.match(regex)[2];

But Javascript also has regex literals built into the language:

return "he says he has never seen " +
   text.match(/I( have|'ve) never seen ([^.,]*)/)[2];

(both return "Invisible has never seen a system that can do that")

Post a reply to this message

Nicolas Alvarez wrote:
> Invisible wrote:
>> "Syntactically JavaScript resembles Java with some influence from Perl,
>> and features Perl-like regular expressions."
>> 
>> Since when does JS have regular expressions?
> 
> Like in Java, you can create a regular expression object with normal
> object-creation syntax, using the RegExp class:
> 
> var regex = new RegExp("I( have|'ve) never seen ([^.,]*)");
> var text = "I've never seen a system that can do that, but...";
> return "he says he has never seen " + text.match(regex)[2];
> 
> But Javascript also has regex literals built into the language:
> 
> return "he says he has never seen " +
>    text.match(/I( have|'ve) never seen ([^.,]*)/)[2];
> 
> (both return "Invisible has never seen a system that can do that")

Er, of course I mean both return "he says he has never seen a system that 
can do that". I replaced "Invisible" in the input texts and didn't change it 
in the last line.

(I was planning to write a regex to find "is obviously impossible", but then 
couldn't find any good sample text in the p.o-t messages still in the 
server; looks like they really did beat that out of your vocabulary :P)

Post a reply to this message