(Apologies to Niklas for multiple copies, it was a Reply/Reply to all mixup.)
On 27/07/06, Niklas Broberg
First of all, programs that import names from the Prelude explicitly would no longer be able to use if-then-else unless they also added 'cond' to that input list (or redefined it of course). This shouldn't really be a problem, since the rebindable syntax is turned on by adding some flag anyway, and if you add that flag you know you're no longer H98. Still, it's going to break a lot of existing programs. The second problem is that it would require the addition of the cond function to the Prelude. This will probably not break too many existing programs, but still it is a more serious problem since it will have effect even without any flags to GHC. Or is it possible to govern the contents of the Prelude based on flags?
How about we drop the idea of an auxilary cond function, and instead just use a Boolean typeclass? class Boolean b where isTrue :: b -> Bool isFalse :: b -> Bool Then the semantics of if-then-else would change to something like this: if b then t1 else t2 b is required to be of a type which instantiates Boolean If isTrue b is True, then t1 is executed, otherwise if isFalse b is True, then t2 is executed, otherwise _|_ is returned. Then you get the benefit of being able to use arbitrary 'boolean-like' types in actual if statements, without messing around with -fno-implicit-prelude and rebindable syntax. -- -David House, dmhouse@gmail.com