Primitive types and Prelude shenanigans

[Marcin 'Qrczak' Kowalczyk]

Wed, 14 Feb 2001 14:19:39 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:

> 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