Changes between Version 1 and Version 2 of Commentary/Compiler/NameType


Ignore:
Timestamp:
Sep 7, 2006 4:48:56 PM (8 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NameType

    v1 v2  
    1 = The {{{!Name}}} and {{{!OccName}}} types = 
     1= The {{{Name}}} and {{{OccName}}} types = 
    22 
    33Every entity (type constructor, class, identifier, type variable) has a {{{Name}}}. The Name type is pervasive in GHC, and is defined in [[GhcFile(compiler/basicTypes/Name.lhs)]]. Here is what a {{{Name}}} looks like, though it is private to the Name module: 
     
    1515 * The {{{n_loc}}} field gives some indication of where the name was bound.  
    1616 
    17 == The NameSort of a Name ==  
     17== The {{{NameSort}}} of a Name ==  
    1818 
    1919There are four flavours of Name:  
     
    3434                        -- OccName is very uninformative (like 's') 
    3535}}} 
    36 Here are the sorts of Name an entity can have:  
    3736 
    38  Class, TyCon:: External.  
    39  Id:: External, Internal, or System.  
    40  TyVar:: Internal, or System.  
     37 {{{Internal}}}, {{{System}}}::          
     38    An {{{Internal}}} {{{Name}}} has only an occurrence name. Distinct {{{Internal}}} {{{Names}}} may have the same occurrence name; the {{{n_uniq}}} distinguishes them.   
    4139 
    42 An External name has a globally-unique (module name, occurrence name) pair, namely the original name of the entity, describing where the thing was originally defined. So for example, if we have  
     40 There is only a tiny difference between {{{Internal}}} and {{{System}}}; the former simply remembers that the name was originally written by the programmer, which helps when generating error messages. 
     41 
     42 {{{External}}}::  
     43    An {{{External}}} {{{Name}}} has a globally-unique (module, occurrence name) pair, namely the original name of the entity, that describes where the thing was originally defined. So for example, if we have  
    4344{{{ 
    4445module M where 
     
    5152  a = Q.f + g 
    5253}}} 
    53 then the RdrNames for "a", "Q.f" and "g" get replaced (by the Renamer) by the Names "A.a", "M.f", and "M.g" respectively.  
     54    then in module {{{A}}}}, the function {{{Q.f}}} has an External Name {{{M.f}}}. 
    5455 
    55 An InternalName has only an occurrence name. Distinct InternalNames may have the same occurrence name; use the Unique to distinguish them.  
     56  During any invocation of GHC, each (module, occurrence-name) gets one, and only one, {{{Unique}}}, stored in the {{{n_uniq}}}} field of the {{{Name}}}.  This assoication remains fixed even when GHC finishes one module and starts to compile another.  This association between (module, occurrence-name) pairs and the corresponding {{{Name}}} (with its {{{n_uniq}}} field) is maintained by the !Name !Cache. 
    5657 
    57 An ExternalName has a unique that never changes. It is never cloned. This is important, because the simplifier invents new names pretty freely, but we don't want to lose the connnection with the type environment (constructed earlier). An InternalName name can be cloned freely.  
    58 Before CoreTidy: the Ids that were defined at top level in the original source program get ExternalNames, whereas extra top-level bindings generated (say) by the type checker get InternalNames. q This distinction is occasionally useful for filtering diagnostic output; e.g. for -ddump-types.  
    59 After CoreTidy: An Id with an ExternalName will generate symbols that appear as external symbols in the object file. An Id with an InternalName cannot be referenced from outside the module, and so generates a local symbol in the object file. The CoreTidy pass makes the decision about which names should be External and which Internal.  
    60 A System name is for the most part the same as an Internal. Indeed, the differences are purely cosmetic:  
    61 Internal names usually come from some name the user wrote, whereas a System name has an OccName like "a", or "t". Usually there are masses of System names with the same OccName but different uniques, whereas typically there are only a handful of distince Internal names with the same OccName.  
    62 Another difference is that when unifying the type checker tries to unify away type variables with System names, leaving ones with Internal names (to improve error messages).  
    63 Occurrence names: OccName 
    64 An OccName is more-or-less just a string, like "foo" or "Tree", giving the (unqualified) name of an entity.  
     58  {{{WiredIn}}}:: 
     59    A {{{WiredIn}}} {{{Name}}} is a special sort of {{{External}}} {{{Name}}}, one that is completely known to the compiler (e.g. the {{{Bool}}} type constructor).  In this case the {{{Name}}} contains the {{{TyThing}}} that it is bound to; no need for lookups here!   
    6560 
    66 Well, not quite just a string, because in Haskell a name like "C" could mean a type constructor or data constructor, depending on context. So GHC defines a type OccName (defined in basicTypes/OccName.lhs) that is a pair of a FastString and a NameSpace indicating which name space the name is drawn from:  
     61  The {{{BuiltInSyntax}}} field is just a boolean yes/no flag that identifies entities that are denoted by built-in syntax, such as {{{[]}}} for the empty list.  These {{{Names}}} aren't "in scope" as such, and we occasionally need to know that. 
    6762 
     63== Entities and {{{Names}}} == 
     64 
     65Here are the sorts of Name an entity can have:  
     66 
     67 * Class, !TyCon: Always have {{{External}}} or {{{WiredIn}}} Names.  
     68 
     69 * !TyVar: can have {{{Internal}}}, or {{{System}}} Names; the former are ones arise from instantiating programmer-written type signatures. 
     70 
     71 * Ids: can have {{{External}}}, {{{Internal}}}, or {{{System}}} Names.  
     72    * Before !CoreTidy, the Ids that were defined at top level in the original source program get {{{External}}} Names, whereas extra top-level bindings generated (say) by the type checker get {{{Internal}}} Names. This distinction is occasionally useful for filtering diagnostic output; e.g. for {{{-ddump-types}}}.  
     73    * After !CoreTidy: An Id with an {{{External}}} Name will generate symbols that appear as external symbols in the object file. An Id with an {{{Internal}}} Name cannot be referenced from outside the module, and so generates a local symbol in the object file. The !CoreTidy pass makes the decision about which names should be External and which Internal.  
     74 
     75 
     76== Occurrence names: {{{OccName}}} ==  
     77 
     78An {{{OccName}}} is more-or-less just a string, like "foo" or "Tree", giving the (unqualified) name of an entity.  
     79Well, not quite just a string, because in Haskell a name like "C" could mean a type constructor or data constructor, depending on context. So GHC defines a type OccName (defined in basicTypes/OccName.lhs) that is a pair of a {{{FastString}}} and a {{{NameSpace}}} indicating which name space the name is drawn from. The data type is defined (abstractly) in [[GhcFile(compiler/basicTypes/OccName.lhs)]]: 
     80{{{ 
    6881data OccName = OccName NameSpace EncodedFS 
    69 The EncodedFS is a synonym for FastString indicating that the string is Z-encoded. (Details in OccName.lhs.) Z-encoding encodes funny characters like '%' and '$' into alphabetic characters, like "zp" and "zd", so that they can be used in object-file symbol tables without confusing linkers and suchlike.  
     82}}} 
     83The {{{EncodedFS}}} is a synonym for {{{FastString}}} indicating that the string is Z-encoded. (Details in [[GhcFile(compiler/basicTypes/OccName.lhs)]].) Z-encoding encodes funny characters like '%' and '$' into alphabetic characters, like "zp" and "zd", so that they can be used in object-file symbol tables without confusing linkers and suchlike.  
    7084 
    7185The name spaces are:  
    7286 
    73 VarName: ordinary variables  
    74 TvName: type variables  
    75 DataName: data constructors  
    76 TcClsName: type constructors and classes (in Haskell they share a name space)  
    77 Last modified: Wed May 4 14:57:55 EST 2005  
     87{{{ 
     88data NameSpace = VarName        -- Variables, including "source" data constructors 
     89               | DataName       -- "Real" data constructors  
     90               | TvName         -- Type variables 
     91               | TcClsName      -- Type constructors and classes; Haskell has them 
     92                                -- in the same name space for now. 
     93}}} 
     94