Primitive types and Prelude shenanigans

[Marcin 'Qrczak' Kowalczyk]

Fri, 16 Feb 2001 04:14:24 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:

> [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