1. 09 Dec, 2012 1 commit
  2. 05 Dec, 2012 1 commit
  3. 22 Feb, 2012 1 commit
  4. 16 Feb, 2012 1 commit
  5. 15 Jan, 2012 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix vectorisation of classes · b68bbd86
      chak@cse.unsw.edu.au. authored
      - Make sure that we have no implicit names in ifaces
      - Any vectorisation info makes a module an orphan module
      - Allow 'Show' in vectorised code without vectorising it for the moment
      b68bbd86
  6. 03 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Major refactoring of CoAxioms · 98a642cf
      Simon Peyton Jones authored
      This patch should have no user-visible effect.  It implements a
      significant internal refactoring of the way that FC axioms are
      handled.  The ultimate goal is to put us in a position to implement
      "pattern-matching axioms".  But the changes here are only does
      refactoring; there is no change in functionality.
      
      Specifically:
      
       * We now treat data/type family instance declarations very,
         very similarly to types class instance declarations:
      
         - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
           FamInstEnv.FamInst.  This change does affect the GHC API, but
           for the better I think.
      
         - Previously, each family type/data instance declaration gave rise
           to a *TyCon*; typechecking a type/data instance decl produced
           that TyCon.  Now, each type/data instance gives rise to
           a *FamInst*, by direct analogy with each class instance
           declaration giving rise to a ClsInst.
      
         - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
           contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
           in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
           two types, whereas the FamInst relates directly to the Haskell source
           language construct, and always has a function (F tys) on the LHS.
      
         - Just as a DFunId has its own declaration in an interface file, so now
           do CoAxioms (see IfaceSyn.IfaceAxiom).
      
         These changes give rise to almost all the refactoring.
      
       * We used to have a hack whereby a type family instance produced a dummy
         type synonym, thus
            type instance F Int = Bool -> Bool
         translated to
            axiom FInt :: F Int ~ R:FInt
            type R:FInt = Bool -> Bool
         This was always a hack, and now it's gone.  Instead the type instance
         declaration produces a FamInst, whose axiom has kind
            axiom FInt :: F Int ~ Bool -> Bool
         just as you'd expect.
      
       * Newtypes are done just as before; they generate a CoAxiom. These
         CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
         unlike the ones coming from family instance declarations.  See
         Note [Implicit axioms] in TyCon
      
      On the whole the code gets significantly nicer.  There were consequential
      tidy-ups in the vectoriser, but I think I got them right.
      98a642cf
  7. 25 Nov, 2011 1 commit
  8. 23 Nov, 2011 2 commits
  9. 18 Nov, 2011 1 commit
  10. 17 Nov, 2011 2 commits
  11. 15 Nov, 2011 2 commits
  12. 14 Nov, 2011 4 commits
  13. 09 Nov, 2011 1 commit
  14. 04 Nov, 2011 1 commit
  15. 31 Oct, 2011 1 commit
  16. 10 Oct, 2011 1 commit
  17. 21 Sep, 2011 1 commit
    • Simon Marlow's avatar
      Add support for all top-level declarations to GHCi · 3db75724
      Simon Marlow authored
        This is work mostly done by Daniel Winograd-Cort during his
        internship at MSR Cambridge, with some further refactoring by me.
      
      This commit adds support to GHCi for most top-level declarations that
      can be used in Haskell source files.  Class, data, newtype, type,
      instance are all supported, as are Type Family-related declarations.
      
      The current set of declarations are shown by :show bindings.  As with
      variable bindings, entities bound by newer declarations shadow earlier
      ones.
      
      Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
      Documentation to follow.
      3db75724
  18. 24 Aug, 2011 1 commit
  19. 18 Aug, 2011 2 commits
  20. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  21. 26 Jan, 2011 1 commit
  22. 15 Dec, 2010 1 commit
  23. 20 Feb, 2011 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Added a VECTORISE pragma · f2aaae97
      chak@cse.unsw.edu.au. authored
      - Added a pragma {-# VECTORISE var = exp #-} that prevents
        the vectoriser from vectorising the definition of 'var'.
        Instead it uses the binding '$v_var = exp' to vectorise
        'var'.  The vectoriser checks that the Core type of 'exp'
        matches the vectorised Core type of 'var'.  (It would be
        quite complicated to perform that check in the type checker
        as the vectorisation of a type needs the state of the VM
        monad.)
      - Added parts of a related VECTORISE SCALAR pragma
      - Documented -ddump-vect
      - Added -ddump-vt-trace
      - Some clean up
      f2aaae97
  24. 09 Sep, 2010 1 commit
  25. 15 Sep, 2010 1 commit
  26. 13 Sep, 2010 2 commits
  27. 09 Sep, 2010 5 commits
  28. 08 Sep, 2010 1 commit