[GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0

[GHC]

#15286: "Can't use Natural in base" when compiling GHC.Natural with -O0
-------------------------------------+-------------------------------------
        Reporter:  alpmestan         |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  libraries/base    |              Version:  8.5
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Building GHC      |  Unknown/Multiple
  failed                             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4880
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by hsyl20):

 The current handling of "wired-in" things such as Integer or Natural is
 very fragile. In your case, as you use type-level nats, GHC implicitly
 needs `Natural` from `GHC.Natural` but it can't access it because
 `GHC.Natural` is also defined in `base`. In `coreSyn/CorePrep.hs` we
 explicitly detect use of Natural when we compile `base` (see
 `guardNaturalUse`) to generate the panic you get. Otherwise GHC would fail
 with something like a "can't find/load interface" error.

 Not allowing to depend on `Natural` in `base` is annoying/stupid. In the
 past I've tried the most obvious solution: put `GHC.Natural` in its own
 package just like we do for `integer-*`. However it's harder for Natural
 than it is for Integer because `GHC.Natural` uses `Exception` (with an
 import cycle) and `Maybe` which are defined in `base`...

 I have written a note to state the problem and some ideas:

 {{{
 GHC has some built-in functions, types, constructors, etc.. These are not
 defined in Haskell and when it encounters them it knows what to do with
 them.

 GHC also knows some Haskell defined functions, types, constructors, etc.
 It can
 use this knowledge to perform code transformation (e.g. constant folding)
 and to
 generate some code (e.g. desugaring lists, deriving instances, etc.).

 In this latter case, GHC has to build the Haskell code defining these
 functions,
 types, constructors, etc. without assuming knowledge of non already built
 Haskell code. For instance, suppose `Integer` data type and functions are
 defined in the "GHC.Integer" module. When building "GHC.Integer" GHC must
 assume
 that it knows nothing about Integer (nor about anything that depends on
 knowing
 Integer).

 It can be tricky: suppose we are building the Dummy module defined as
 follow:

    {-# LANGUAGE NoImplicitPrelude #-}
    module Dummy where
       dummy = 0

 Even if Dummy doesn't depend on anything, GHC will default the type of
 "dummy"
 to Integer! So when building this module, there is an implicit dependency
 on
 knowing Integer and GHC.Integer must have been built already for GHC to
 query
 some stuff from it. In this case we could change the default or fix the
 type to
 avoid the dependency or to make it explicit:

    {-# LANGUAGE NoImplicitPrelude #-}
    module Dummy where
       default (Int)
       -- or: dummy :: Int
       -- or: import GHC.Integer ()
       dummy = 0


 At the time of writing, these dependencies are manually handled this way
 (in
 base, etc.) This is very fragile (see #15286).

 -------------

 Ideas:

 1) we should automatically detect implicit dependencies: when GHC is about
 to
 use a builtin Name or Id, it should:
    - detect the dependency it comes from
    - detect cyclic dependencies with the current module
    - ensure the dependency is built
    - clearly indicate why it can't build the implicit dependency if it
 happens

 Shouldn't be too hard: GHC should pretend the module contains an implicit
 "import" when it is about to use a builtin. GHC could even "source import"
 dependencies when there is a cycle because it would mean we compile the
 package
 containing both modules.

 A minor issue is that this implicit import could appear quite late in the
 compilation pipeline (during desugaring, deriving, maybe codegen, etc.):
 GHC
 could have to switch from building the current module to build the
 dependencies
 or fail and indicate to the caller the dependencies to build beforehand.
 The
 latter would be relatively slow because GHC would need to start compiling
 the
 module again and may fail the same way further in the compilation pipeline
 until
 all dependencies are built.

 2) GHC shouldn't assume knowledge of unit IDs. We should be able to
 disable
 whole builtin stuff at once.

 E.g. when building integer-* packages, GHC uses predefined unit-id with
 the
 parameter: -this-unit-id integer-wired-in

 We should avoid this: instead GHC should query the unit-id of the
 integer-*
 package somehow (or use one given on the command line to allow easy switch
 between integer packages). We should also allow the possibility of
 compiling
 without integer-* package at all: this is what is implicitly assumed by
 GHC when
 it builds ghc-prim and integer-* packages (see `guardIntegerUse` in
 coreSyn/CorePrep.hs).

 Instead of relying on knowing two blessed integer-* packages, GHC could
 detect
 the presence of constructors such as "S#" in the given integer package so
 to use
 rules and generate code accordingly. It would make trying new
 releases/implementations of those much easier.

 Same for other packages (natural, base, template-haskell, etc.). E.g. we
 should
 be able to disable template-haskell, etc. When some dependencies are
 disabled/missing, GHC can't produce code using them nor use builtin rules
 assuming it knows them.
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15286#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler