Changes between Version 2 and Version 3 of ReplacingGMPNotes/HaskellLibrary


Ignore:
Timestamp:
Sep 13, 2007 3:37:48 PM (7 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReplacingGMPNotes/HaskellLibrary

    v2 v3  
    77The downside is speed, of course.  The upside is that (a) you don't need GMP and (b) it's relatively easy to do. 
    88 
    9 Becuase of the speed issue we can't abandon GMP, so you'd have to give a new flag to GHC, say `-integer-package=my-integer-2.0`.  The intention would be that the compiler would then use the `Integer` library in package `my-integer-2.0` instead of GMP. 
     9Because of the speed issue we can't abandon GMP.  So there are two possibilities:  
     10  * '''Easy''': add a build-time option so that you can build GHC with GMP, or instead build GHC with a Haskell Integer library.  Disadvantage: there would be two versions of (say) `ghc-6.8`:  
     11    * vanilla `ghc-6.8` using GMP 
     12    * `ghc-6.8-special` with Haskell Integer library 
     13 
     14  * '''Harder''': give a new flag to GHC, say `-integer-package=my-integer-2.0`.  The intention would be that the compiler would then use the `Integer` library in package `my-integer-2.0` instead of GMP.  Advantage: only one version of GHC. 
    1015 
    1116Here are some notes on what you'd need to do to achieve this. 
    1217You'll have to change three bits: 
     18 * The libraries 
    1319 * The compiler 
    1420 * The runtime system 
    15  * The libraries 
     21 
     22== The libraries == 
     23 
     24Currently `Integer` is defined in the module `GHC.Num`.  It would not be hard to pull out the `Integer` stuff, into a separate module `GHC.Integer` (exporting a well-defined interface, and not exposing the representation of `Integer`) that `GHC.Num` imported.  `GHC.Num` is where class `Num` is defined, and `Num` uses `Integer` in the type of the class method `fromInteger`; that's why `GHC.Num` has to import `Integer` and not the other way round.  
     25 
     26Then for the "easy" plan, you could simply change the import so that instead of `GHC.Num` importing `GHC.Integer` it imported `MyIntegerModule` or whatever.  Now recompile all libraries. 
     27 
     28The tricky bit about the "harder" plan is that you'll need to build the libraries twice; once with `GHC.Num` importing `GHC.Integer`, and once with `GHC.Num` importing your `MyIntegerModule` instead.  You'd need to ship GHC with both sets of libraries; the `-integer-package` flag would select which set of libraries you use when compiling and linking.  It's rather unclear exactly how to do this so that it works nicely with Cabal etc. 
    1629 
    1730== The compiler == 
    1831 
    19 GHC knows relatively little about the `Integer` type. Look in `prelude\PrelNames` and search for `Integer`.  These `Names` "know" which module the functions are defined in; look at the defn of `plusIntegerName` for example.  The flag needs to change this defining module, which is a little awkward since `plusIntegerName` is a top-level defn. 
     32GHC knows relatively little about the `Integer` type. Look in `prelude/PrelNames` and search for `Integer`.  These `Names` "know" which module the functions are defined in; look at the defn of `plusIntegerName` for example.   
    2033 
    21 This would have to change.  At the places where `plusIntegerName` is looked up, you'd need to check the flag, and look up something different.  Not hard though. 
     34Currently, then, GHC expects the type `Integer` and the value `plusInteger` to be defined in `GHC.Num`.  That's fine: just add defns like this: 
     35{{{ 
     36module GHC.Num where 
     37  import GHC.Integer( Integer, plusInteger, ... ) as I 
     38    -- or import MyIntegerModule(...) as I 
     39 
     40  type Integer = I.Integer 
     41  plusInteger = I.plusInteger 
     42  ...etc... 
     43}}} 
     44Now GHC will still find `GHC.Num.Integer` but it'll find a type synonym that will tell it where `Integer` is ''really'' defined.  Similarly `plusInteger`. 
    2245 
    2346Integer ''literals'' are built by the desugarer in `DsUtils.mkIntegerExpr`.  All it assumes is that there are functions: 
     
    2649  plusInteger, timesInteger :: Integer -> Integer -> Integer 
    2750}}} 
    28 It uses these functions to construct big integer literals using arithmetic. Despite the name, it's not important that `smallIntegerDataCon` is bound to a data constructor. All the library needs to provide is a way to convert an `Int` to an `Integer` 
     51It uses these functions to construct big integer literals using arithmetic. Despite the name, it's not important that `smallIntegerDataCon` is bound to a data constructor. All the library needs to provide is a way to convert an `Int` to an `Integer`.  So that can be handled just the same way as above. 
    2952 
    30 == The libraries == 
    31  
    32 Currently `Integer` is defined in the module `GHC.Num`.  It would not be hard to pull out the `Integer` stuff, so that we had `GHC.Integer` (exporting well-defined interface) that `GHC.Num` imported.  `GHC.Num` is where class `Num` is defined, and `Num` uses `Integer` in the type of the class method `fromInteger`; that's why `GHC.Num` has to import `Integer` and not the other way round. 
    33  
    34 The tricky bit is that you'll need to build the libraries twice; once with `GHC.Num` importing `GHC.Integer`, and once with `GHC.Num` importing your new `Integer` library instead.  You'd need to ship GHC with both sets of libraries; the `-integer-package` flag would select which set of libraries you use when compiling and linking.  We already have this library-version issue with profiling; but you've just doubled the number of library builds! 
     53In short, the compiler can be untouched EXCEPT for any jiggery pokery to do with finding the right libraries when using the "harder" approach. 
    3554 
    3655== The runtime system ==