1. 12 Jan, 2014 1 commit
  2. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
          Note [The interactive package]
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          This scheme deals well with shadowing.  For example:
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
  3. 02 Dec, 2013 2 commits
  4. 27 Nov, 2013 2 commits
    • Joachim Breitner's avatar
      Get rid of EvCoercible · 808ded9c
      Joachim Breitner authored
      and use EvCoercion to describe the evidence for Coercible instances.
    • Joachim Breitner's avatar
      Roleify TcCoercion · 9d643cf6
      Joachim Breitner authored
      Previously, TcCoercion were only used to represent boxed Nominal
      coercions. In order to also talk about boxed Representational coercions
      in the type checker, we add Roles to TcCoercion. Again, we closely
      mirror Coercion.
      The roles are verified by a few assertions, and at the latest after
      conversion to Coercion. I have put my trust in the comprehensiveness of
      the testsuite here, but any role error after desugaring popping up now
      might be caused by this refactoring.
  5. 22 Nov, 2013 4 commits
    • Simon Peyton Jones's avatar
      Replace (State# RealWorld) with Void# where we just want a 0-bit value · f4384647
      Simon Peyton Jones authored
      We were re-using the super-magical "state token" type (which has
      VoidRep and is zero bits wide) for situations in which we simply want
      to lambda-abstract over a zero-bit argument. For example, join points:
         case (case x of { True -> e1; False -> e2 }) of
            Red  -> f1
            Blue -> True
        let $j1 = \voidArg::Void# -> f1
        case x of
          True -> case e1 of
                    Red -> $j1 void
                    Blue -> True
          False -> case e2 of
                    Red -> $j1 void
                    Blue -> True
      This patch introduces
         * The new primitive type GHC.Prim.Void#, with PrimRep = VoidRep
         * A new global Id GHC.Prim.voidPrimId :: Void#.
           This has no binding because the code generator drops it,
           but is used as an argument (eg in the call of $j1)
         * A new local Id, MkId.voidArgId, which can be lambda-bound
           when you need to lambda-abstract over it.
      and uses them throughout.
      Now the State# thing is used only when we need state!
    • Simon Peyton Jones's avatar
      Move isVoidRep, isGcPtrRep to TyCon to join primRepSizeW etc · b83666d4
      Simon Peyton Jones authored
      This is just a modest refactoring
    • Joachim Breitner's avatar
      Extend Coercible to newtype instances · 335031f0
      Joachim Breitner authored
      This fixes: #8548
    • Simon Peyton Jones's avatar
      Fix type-equality in the type checker (fixes Trac #8553) · 985663ea
      Simon Peyton Jones authored
      For horrible reasons (Note [Comparison with OpenTypeKind] in Type), the
      function Type.eqType currently equates OOpenKind with *.  This may or may
      not be a good idea (it's certainly a revolting one) but it DOES NOT WORK
      in the type checker, which *does* need to distinguish OpenKind and *.
      Rather than solve the underlying problem (I have some ideas) I just
      introduced a new, and very short, simple, straightforward function
      TcType.tcEqType to do the job.
  6. 20 Nov, 2013 1 commit
  7. 14 Nov, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Change the representation and move TcBuiltInSynFamily. · 19b8809c
      Iavor S. Diatchki authored
      The changes in more detail:
        * `TcBuiltInSynFamily` is now known as `BuiltinSynFamily` and
           lives in `CoAxiom`
        * `sfMatchFam` returns (CoAxiomRule, [Type], Type),
           which is enough to make Coersion or TcCoercion,
           depending on what what we need.
        * The rest of the compiler is updated to reflect these changes,
          most notably we can eliminate the cludge (XXX) in FamInstEnv
          and remove the lhs-boot file.
  8. 13 Nov, 2013 2 commits
    • parcs's avatar
      Remove unnecessary and deprecated inclusions of Typeable.h · 117b6b8d
      parcs authored
      The build system would've complained loudly about these inclusions if it
      weren't for #8527.
    • Iavor S. Diatchki's avatar
      Make type-level evaluation work with :kind! · b2fa2d41
      Iavor S. Diatchki authored
      The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
      built-in type constructors (e.g., (+), (*), and friends).
      To avoid problems with recursive modules, I moved the definition of
      TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not sure if
      this is the right place.
      There is also a wibble that it'd be nice to fix:
      when we evaluate a built-in type function, using`sfMatchFam`, we get
      a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a `Corecion`.
      I couldn't find a nice way to convert between the two, so I resorted to
      a bit of hack (marked with `XXX`).
      The hack is that we happen to know that the built-in constructors for
      the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
      with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
      in this one case.  This is enough to make things work, but it is clearly
      a cludge.
  9. 06 Nov, 2013 1 commit
  10. 01 Nov, 2013 1 commit
  11. 24 Oct, 2013 5 commits
  12. 23 Oct, 2013 3 commits
  13. 12 Oct, 2013 1 commit
  14. 09 Oct, 2013 2 commits
  15. 03 Oct, 2013 1 commit
  16. 01 Oct, 2013 7 commits
  17. 20 Sep, 2013 1 commit
  18. 18 Sep, 2013 3 commits
  19. 13 Sep, 2013 1 commit