Fri, 16 Feb 2001 04:14:24 -0800, Simon Peyton-Jones
[Incidentally, if this is nhc's behaviour, it's not H98. The Report (tries to) stress that you get the "fromInt from the actual standard Prelude" regardless of what is in scope. That's why I'm not going to make it the default behaviour.]
But is mere -fglasgow-exts enough to enable it? BTW: fromInt is not H98. However when a compiler uses fromInt instead of fromInteger where the number fits, with a suitable default method for fromInt which is not exported from Prelude, then no program can tell the difference, so it's OK. Unfortunately integer literals cannot expand to Prelude.fromInt, because Prelude does not export fromInt! Currently ghc extension flags can have no effect on module imports, so if fromInt is not visible in standard mode, it will not visible in extended mode either. In such case these two extensions (Prelude substitution and using fromInt for integer literals) are incompatible.
Marcin suggests that 'if' is just syntactic sugar. But that would be a disaster if the new Bool type didn't have constructors True and False.
Correction: it would be a disaster when there are no Prelude.True and Prelude.False constructors of the same type. It needs not to be called Bool if the desugaring rule does not say so.
Here I think the right thing is to say that desugaring for boolean constructs uses a function 'if' assumed to have type if :: forall b. Bool -> b -> b -> b
What if somebody wants to make 'if' overloaded on more types than some constant type called Bool? class Condition a where if :: a -> b -> b -> b Generally I don't feel the need of allowing to replace if, Bool and everything else with custom definitions, especially when there is no single obvious way. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK