Changes between Version 14 and Version 15 of Commentary/Compiler/WiredIn


Ignore:
Timestamp:
Jul 17, 2015 10:06:19 PM (4 years ago)
Author:
rodlogic
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/WiredIn

    v14 v15  
    1414A '''Wired-in thing''' is fully known to GHC.  Most of these are `TyCon`s such as `Bool`. It is very convenient to simply be able to refer to `boolTyCon :: TyCon` without having to look it up in an environment. 
    1515
    16 All [wiki:Commentary/Compiler/TypeType#Classifyingtypes primitive types] are wired-in things, and have wired-in `Name`s.  The primitive types (and their `Names`) are all defined in [[GhcFile(compiler/prelude/TysPrim.lhs)]].
     16All [wiki:Commentary/Compiler/TypeType#Classifyingtypes primitive types] are wired-in things, and have wired-in `Name`s.  The primitive types (and their `Names`) are all defined in [[GhcFile(compiler/prelude/TysPrim.hs)]].
    1717
    18 The non-primitive wired-in type constructors are defined in [[GhcFile(compiler/prelude/TysWiredIn.lhs)]].  There are a handful of wired-in `Id`s in [[GhcFile(compiler/basicTypes/MkId.lhs)]]. There are no wired-in classes (they are too complicated).
     18The non-primitive wired-in type constructors are defined in [[GhcFile(compiler/prelude/TysWiredIn.hs)]].  There are a handful of wired-in `Id`s in [[GhcFile(compiler/basicTypes/MkId.hs)]]. There are no wired-in classes (they are too complicated).
    1919
    20 All the non-primitive wired-in things are ''also'' defined in GHC's libraries, because even though GHC knows about them we still need to generate code for them. For example, `Bool` is a wired-in type constructor, but it is still defined in `GHC.Base` because we need the info table etc for the data constructors.  Arbitrarily bad things will happen if the wired-in definition in [[GhcFile(compiler/prelude/TysWiredIn.lhs)]] differs from that in the library module.
     20All the non-primitive wired-in things are ''also'' defined in GHC's libraries, because even though GHC knows about them we still need to generate code for them. For example, `Bool` is a wired-in type constructor, but it is still defined in `GHC.Base` because we need the info table etc for the data constructors.  Arbitrarily bad things will happen if the wired-in definition in [[GhcFile(compiler/prelude/TysWiredIn.hs)]] differs from that in the library module.
    2121
    2222All wired-in things have a `WiredIn` `Name` (see [wiki:Commentary/Compiler/NameType Names]), which in turn contains the thing.  See [wiki:Commentary/Compiler/CaseStudies/Bool a case study of Bool implementation] for more details.
     
    2828 * Its `OccName`
    2929 * Its `Unique`
    30 Almost all known-key names are defined in [[GhcFile(compiler/prelude/PrelNames.lhs)]]; for example: {{{PrelNames.eqClassName :: Name}}}.
     30Almost all known-key names are defined in [[GhcFile(compiler/prelude/PrelNames.hs)]]; for example: {{{PrelNames.eqClassName :: Name}}}.
    3131
    3232The point about known-key things is that GHC knows its ''name'', but not its ''definition''.  The definition must still be read from an interface file as usual. The known key just allows an efficient lookup in the environment.
     
    5353  * Its defining `Module`
    5454  * Its `OccName`
    55 Again, almost all of these are in [[GhcFile(compiler/prelude/PrelNames.lhs)]].
     55Again, almost all of these are in [[GhcFile(compiler/prelude/PrelNames.hs)]].
    5656Example: {{{PrelNames.not_RDR :: RdrName}}}.