On Tue, 4 Nov 2014, Sean Hunt wrote: > On Tue, Nov 4, 2014 at 12:40 PM, Kerim Aydin <[email protected]> wrote: > > Anyway, my point was not to defend Murphy's argument, but to point out > > that "something turning out indeterminate as a result" is not a > > particularly compelling counterargument. > > I am inclined to believe that the fact that the result is > indeterminate is the indication that there is ambiguity, and thus the > rule change must fail. The burden set upon rule changes to be > unambiguous is extremely high. I think that it should be interpreted > broadly as any ambiguity material to the rule change, not only to its > content.
Agreed. If I were to pin it on something, I might combine your logic with the fact that the Rulekeepor tracks date and version numbers which implicitly requires tracking sequence of adoption (though not in all cases!) I was mainly challenging what seemed to be the following false syllogism: 1. Ambiguous Rule changes, if allowed, would lead to an indeterminate result. 2. This rule change, if allowed, would lead to an indeterminate result; 3. Therefore this rule change is ambiguous. Point being, you can have very clearly-specified rule changes that still lead to an indeterminate result (like if you make a rule change conditional on a divide by 0). -G.
