Tue, 16 May 2000 00:37:04 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> import Prelude ()
> nil :: [a]
> nil = []
> or
> import Prelude ()
> cons :: a -> [a]
> cons h t = h : t
> ghc rejects them both,
But does not reject if "import Prelude ()" is changed to "import
qualified Prelude", which is strange - they should have the same
effect on names that are not qualified!
IMHO the best way to fix the standard is to let all these special
syntactic constructs be always available. It's not necessary to provide
means to export them, redefine them, or qualify them. Similarly as
the do notation is available even when Prelude.>>= is not in scope,
and there is no reason to be able to qualify commas in [1,2,3].
This includes type constructors:
()
[]
(,) (,,) (,,,) etc.
->
value constructors:
()
[]
(,) (,,) (,,,) etc.
:
and unary negation - whose exceptionalness is required anyway, to form
negative numeric literals in patterns.
BTW. The report is not clear whether unary negation in patterns means
comparison with fromInteger applied to the negated value or with
overloaded negate applied to fromInteger applied to the nonnegative
value. GHC does the former, and I like it, although in expressions
negation means the latter.
GHC has strange behavior on perverse numeric instances. Given this:
newtype T = T Integer deriving (Show)
instance Eq T
instance Num T
main = putStrLn $ case T 2 of
4 -> "4"
_ -> "_"
it outputs 4, even though (==) and fromInteger are undefined. With
(==) explicitly defined as undefined, it fails as expected - but
omitting the (==) definition should give the same effect (modulo
the error message). It seems to not use fromInteger at all, even in
expressions, if T is a newtype for Int or Integer, but uses it for
other types and always for data.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
