From: Joe E. <jen...@fl...> - 2007-10-18 20:10:28
|
Donald G Porter wrote: > A number of alternative schemes for changing Tcl's octal parsing rules > are being suggested. Here I try to summarize the options that seem > plausibly useful to me. The summary is in terms of what each option > would do to the strings "01", "08", and "010". It's also useful to highlight how the strings "017" and "018" are interpreted under each option: > Option 0: Leave things as they are: > > "01" : Legal integer value 1 > "08" : Error > "010" : Legal integer value 8 "017" : Legal integer value 15 "018" : Error > Option 1: Compatible change. "invalid octal" -> decimal > > "01" : Legal integer value 1 > "08" : Legal integer value 8 > "010" : Legal integer value 8 "017" : Legal integer value 15 "018" : Legal integer value 18 (!!!) > Option 2: Noisy incompatible change. Ambiguous leading zero -> error. > > "01" : Legal integer value 1 > "08" : Error > "010" : Error "017" : Error "018" : Error > Option 3: Noisy incompatible change. All leading zero -> error. > > "01" : Error > "08" : Error > "010" : Error "017" : Error "018" : Error > Option 4: Silent incompatible change. All parsing is decimal. > > "01" : Legal integer value 1 > "08" : Legal integer value 8 > "010" : Legal integer value 10 "017" : Legal integer value 17 "018" : Legal integer value 18 Option 1 would lead to inconsistencies that are even worse than what we have today: you'd get [expr {018 - 017}] ==> 3 (!), and how do you explain *that* to confused newbies? Option 2 doesn't go far enough to help much: scripts that use octal on purpose would break, but scripts that use octal by accident would still appear to work 10 months out of the year and only break in August and September. Option 3 does go far enough. Option 4 is, I believe, where we want to end up. My opinion: Options 1 and 2 are unacceptable (1 because of inconsistencies, 2 because it's just not worth doing.) Options 0, 3, and 4 are OK. I confess that I'm leaning towards option 0 for Tcl 8.5. The new "0o" syntax for explicit octals provides a future-proof upgrade path for code that uses octals on purpose; if the 8.5 release notes include a prominent warning that octal syntax for integers is on the hit list, we can move to option 3 or 4 at a later date. That said, I would be OK with either (3) or (4) in 8.5. --Joe English |