Wed, 14 Feb 2001 14:19:39 -0800, Simon Peyton-Jones
Some while ago I modified GHC to have an extra runtime flag to let you change this behaviour. The effect was that 3 turns into simply (fromInt 3), and the "fromInt" means "whatever fromInt is in scope".
Wasn't that still fromInteger?
I think I managed to forget to tell anyone of this flag.
I remember that it has been advertised.
And to my surprise I can't find it any more!
Me neither. But it's still documented. It must have been list during some branch merging I guess. May I propose an alternative way of specifying an alternative Prelude? Instead of having a command line switch, let's say that 3 always means Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag. I see only one problem with that: inside the module MyPrelude it is not visible as Prelude yet. But it's easy to fix. Just allow a module to import itself! module MyPrelude where import Prelude as P import MyPrelude as Prelude Now names qualified with Prelude refer to entities defined in this very module, including implicit Prelude.fromInteger. I don't know if such self-import should hide MyPrelude qualification or not. I guess it should, similarly as explicit import of Prelude hides its implicit import. That is, each module implicitly imports itself, unless it imports itself explicitly (possibly under a different name) - same as for Prelude.
So much for numerics. It's much less obvious what to do about booleans.
IMHO a natural generalization (not necessarily useful) is to follow the definition of the 'if' syntactic sugar literally. 'if' expands to the appropriate 'case'. So Prelude.True and Prelude.False must be defined, and they must have the same type (otherwise we get a type error each time we use 'if'). This would allow even data FancyBool a = True | False | DontKnow a The main problem is probably the current implementation: syntactic sugar like 'if' is typechecked prior to desugaring. The same problem is with the 'do' notation. But I don't see conceptual dilemmas.
For example, can we assume that f x | otherwise = e is equivalent to f x = e
We should not need this information except for performance and warnings. Semantically otherwise is just a normal variable. So it does not matter much. Non-standard 'otherwise' is the same as currently would be foo :: Bool foo = True The compiler could be improved by examining the unfolded definition for checking whether to generate warnings, instead of relying on special treatment of the particular qualified name. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK