On Fri, 15 Dec 2000, Tom Christiansen wrote: > >We may have to "agree to disagree". > > I shan't be doing that. Well, I'm still willing to discuss it, as long as it remains a discussion and doesn't become a flame war. > >I'm understand why people believe in > >the current semantics, but I've seen no indication that anyone else > >understands why I believe in these alternative semantics, or has tried. > >(Disagreeing with my conclusion doesn't preclude understanding where I'm > >coming from, but nobody seems to.) > > You have not addressed the heat death of the universe as I and > others have illustrated. Finding all possible matches is very often > completely infeasible. Please solve the electron decay problem > before continuing. Where does the heat death of the universe come in? I can give you a SIMPLE way to implement it, but I doubt it's the best way: apply the current rules first, then take the matching substring and search within THAT for a match with the priority of the rules inverted -- prefer non-greediness OVER leftmost matching for the second pass. This WILL get the result I suggest, preferring leftmost matching in general while still maximizing the amount non-greediness (stinginess) within those constraints. At worst, this should take no more than double the amount of time that the single pass did, probably less. Hardly a cause to concern ourselves with the heat death of the universe. Note, I do NOT recommend that implementation; it imposes an obvious speed penalty that shouldn't be imposed on people who don't care. It might make sense as an option, however. However, it does bring another possibility to mind. For those who are willing to pay a 100% speed penalty for simplicity, this sort of two-pass mode could be allowed, and allow juggling of both preferences? Maybe it would be useful to allow a "rightmost matching preference" option for people who could use it. (Might be helpful when working with Hebrew?) > >Well, obviously we could. Maybe we shouldn't, but we could do it. Many, > >many existing programs depended on Perl 4's magic behavior with @'s in > >double-quoted strings, yet Perl 5 broke them all with a fatal error during > >the compile phase. People survived. They adapted and moved on. > > Red herring. Counterexample to the assumption that we can't break existing code by changing the semantics. It's been done before, it could happen again. > >Unlike that incompatibility, this one would probably affect few > >programs. > > You're wrong. Incredibly wrong. Really? Do you have a real-world example that it would break, which would demonstrate how common such breakage would be? Deven