Skip to content
Snippets Groups Projects
  • Simon Peyton Jones's avatar
    02ed7d78
    Refactor mkRuntimeError · 02ed7d78
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    This patch fixes #22634.  Because we don't have TYPE/CONSTRAINT
    polymorphism, we need two error functions rather than one.
    
    I took the opportunity to rname runtimeError to impossibleError,
    to line up with mkImpossibleExpr, and avoid confusion with the
    genuine runtime-error-constructing functions.
    02ed7d78
    History
    Refactor mkRuntimeError
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    This patch fixes #22634.  Because we don't have TYPE/CONSTRAINT
    polymorphism, we need two error functions rather than one.
    
    I took the opportunity to rname runtimeError to impossibleError,
    to line up with mkImpossibleExpr, and avoid confusion with the
    genuine runtime-error-constructing functions.
Names.hs 117.03 KiB
{-
(c) The GRASP/AQUA Project, Glasgow University, 1992-1998

\section[GHC.Builtin.Names]{Definitions of prelude modules and names}


Nota Bene: all Names defined in here should come from the base package

 - ModuleNames for prelude modules,
        e.g.    pREL_BASE_Name :: ModuleName

 - Modules for prelude modules
        e.g.    pREL_Base :: Module

 - Uniques for Ids, DataCons, TyCons and Classes that the compiler
   "knows about" in some way
        e.g.    intTyConKey :: Unique
                minusClassOpKey :: Unique

 - Names for Ids, DataCons, TyCons and Classes that the compiler
   "knows about" in some way
        e.g.    intTyConName :: Name
                minusName    :: Name
   One of these Names contains
        (a) the module and occurrence name of the thing
        (b) its Unique
   The way the compiler "knows about" one of these things is
   where the type checker or desugarer needs to look it up. For
   example, when desugaring list comprehensions the desugarer
   needs to conjure up 'foldr'.  It does this by looking up
   foldrName in the environment.

 - RdrNames for Ids, DataCons etc that the compiler may emit into
   generated code (e.g. for deriving).  It's not necessary to know
   the uniques for these guys, only their names


Note [Known-key names]
~~~~~~~~~~~~~~~~~~~~~~
It is *very* important that the compiler gives wired-in things and
things with "known-key" names the correct Uniques wherever they
occur. We have to be careful about this in exactly two places:

  1. When we parse some source code, renaming the AST better yield an
     AST whose Names have the correct uniques

  2. When we read an interface file, the read-in gubbins better have
     the right uniques

This is accomplished through a combination of mechanisms:

  1. When parsing source code, the RdrName-decorated AST has some
     RdrNames which are Exact. These are wired-in RdrNames where
     we could directly tell from the parsed syntax what Name to
     use. For example, when we parse a [] in a type we can just insert
     an Exact RdrName Name with the listTyConKey.

     Currently, I believe this is just an optimisation: it would be
     equally valid to just output Orig RdrNames that correctly record
     the module etc we expect the final Name to come from. However,
     were we to eliminate isBuiltInOcc_maybe it would become essential
     (see point 3).

  2. The knownKeyNames (which consist of the basicKnownKeyNames from
     the module, and those names reachable via the wired-in stuff from
     GHC.Builtin.Types) are used to initialise the "OrigNameCache" in
     GHC.Iface.Env.  This initialization ensures that when the type checker
     or renamer (both of which use GHC.Iface.Env) look up an original name
     (i.e. a pair of a Module and an OccName) for a known-key name
     they get the correct Unique.