1. 07 Aug, 2008 3 commits
  2. 31 Jul, 2008 6 commits
  3. 20 Jul, 2008 1 commit
  4. 08 Jul, 2008 1 commit
  5. 14 Jun, 2008 2 commits
  6. 05 Jun, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add non-recursive let-bindings for types · 1b1190e0
      simonpj@microsoft.com authored
      This patch adds to Core the ability to say
      	let a = Int in <body>
      where 'a' is a type variable.  That is: a type-let.
      See Note [Type let] in CoreSyn.
      * The binding is always non-recursive
      * The simplifier immediately eliminates it by substitution 
      So in effect a type-let is just a delayed substitution.  This is convenient
      in a couple of places in the desugarer, one existing (see the call to
      CoreTyn.mkTyBind in DsUtils), and one that's in the next upcoming patch.
      The first use in the desugarer was previously encoded as
      	(/\a. <body>) Int
      rather that eagerly substituting, but that was horrid because Core Lint
      had do "know" that a=Int inside <body> else it would bleat.  Expressing
      it directly as a 'let' seems much nicer.
  7. 03 Jun, 2008 1 commit
  8. 28 May, 2008 1 commit
    • Simon Marlow's avatar
      Use MD5 checksums for recompilation checking (fixes #1372, #1959) · 526c3af1
      Simon Marlow authored
      This is a much more robust way to do recompilation checking.  The idea
      is to create a fingerprint of the ABI of an interface, and track
      dependencies by recording the fingerprints of ABIs that a module
      depends on.  If any of those ABIs have changed, then we need to
      In bug #1372 we weren't recording dependencies on package modules,
      this patch fixes that by recording fingerprints of package modules
      that we depend on.  Within a package there is still fine-grained
      recompilation avoidance as before.
      We currently use MD5 for fingerprints, being a good compromise between
      efficiency and security.  We're not worried about attackers, but we
      are worried about accidental collisions.
      All the MD5 sums do make interface files a bit bigger, but compile
      times on the whole are about the same as before.  Recompilation
      avoidance should be a bit more accurate than in 6.8.2 due to fixing
      #1959, especially when using -O.
  9. 04 May, 2008 2 commits
  10. 12 Apr, 2008 7 commits
  11. 22 Apr, 2008 4 commits
    • simonpj@microsoft.com's avatar
      Simplify SimplCont, plus some other small changes to the Simplifier · 53f99d84
      simonpj@microsoft.com authored
      The main change in this patch is this:
        * The Stop constructor of SimplCont no longer contains the OutType
          of the whole continuation.  This is a nice simplification in 
          lots of places where we build a Stop continuation.  For example,
          rebuildCall no longer needs to maintain the type of the function.
        * Similarly StrictArg no longer needs an OutType
        * The consequential complication is that contResultType (not called
          much) needs to be given the type of the thing in the middle.  No
          big deal.
        * Lots of other small knock-on effects
      Other changes in here
        * simplLazyBind does do the type-abstraction thing if there's
          a lambda inside.  See comments in simplLazyBind
        * simplLazyBind reduces simplifier iterations by keeping 
          unfolding information for stuff for which type abstraction is 
          done (see add_poly_bind)
      All of this came up when implementing System IF, but seems worth applying
      to the HEAD
    • simonpj@microsoft.com's avatar
    • chevalier@alum.wellesley.edu's avatar
      Improve External Core syntax for newtypes · e4417dcd
      chevalier@alum.wellesley.edu authored
      I was confused by the newtype eta-contraction trick before.
      Newtype declarations are much less redundant now.
    • chevalier@alum.wellesley.edu's avatar
      Naming changes in External Core · b0045fdd
      chevalier@alum.wellesley.edu authored
      Two changes:
      - Top-level bindings in a given module are now printed as a 
        single %rec group. I found that in External Core generated from
        optimized code, nonrec bindings weren't being printed in
        dependency order. Rather than fixing that, I decided to not
        even pretend to preserve dependency order (since there's
        recursion between modules anyway.)
      - Internal names are now printed with their uniques attached
        (otherwise, GHC was printing out code with shadowed bindings,
        and this isn't supposed to happen in External Core.)
  12. 16 Apr, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Improve External Core syntax · 2ad4df60
      chevalier@alum.wellesley.edu authored
      Got rid of the silly '^' characters before qualified names (plus:
      reverts to the original syntax; minus: makes the parser a little
      Also, added warning in the typechecker for coercion kind mismatches
      rather than considering that a type error. (see the added comment in
      Check.hs for details.)
  13. 14 Apr, 2008 1 commit
  14. 10 Apr, 2008 2 commits
    • simonpj@microsoft.com's avatar
      Ensure that arity is accurate in back end · 3dcb2a66
      simonpj@microsoft.com authored
      See Note [exprArity invariant] in CoreUtils.  In code generated by Happy
      I was seeing this after TidyPgm and CorePrep
      	f :: Any
      	f {arity 1} = id `cast` unsafe-co
      So f claimed to have arity 1 (because exprArity looked inside), but
      did not have any top-level lambdas (because its type is Any).  
      This triggered a slightly-obscure ASSERT failure in CoreToStg
      This patch 
      	- makes exprArity trim the arity if the type is not a function
      	- adds a stronger ASSERT in TidyPgm
      It's not the only way to solve this problem (see Note [exprArity invariant])
      but it's enough for now. 
    • chevalier@alum.wellesley.edu's avatar
      Another round of External Core fixes · 4c6a3f78
      chevalier@alum.wellesley.edu authored
      With this patch, GHC should now be printing External Core in a format
      that a stand-alone program can parse and typecheck. Major bug fixes:
      - The printer now handles qualified/unqualified declarations correctly
         (particularly data constructor declarations)
      - It prints newtype declarations with enough information to
        typecheck code that uses the induced coercions (this required a
      syntax change)
      - It expands type synonyms correctly
      Documentation and external tool patches will follow.
  15. 29 Mar, 2008 3 commits
  16. 28 Mar, 2008 2 commits
  17. 27 Mar, 2008 1 commit
  18. 25 Mar, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Change syntax for newtypes in External Core · 2fbab1a0
      chevalier@alum.wellesley.edu authored
      The way that newtype declarations were printed in External Core files was
      incomplete, since there was no declaration for the coercion introduced by a
      For example, the Haskell source:
      newtype T a = MkT (a -> a)
      foo (MkT x) = x
      got printed out in External Core as (roughly):
        %newtype T a = a -> a;
        foo :: %forall t . T t -> t -> t =
          %cast (\ @ t -> a1 @ t)
          (%forall t . T t -> ZCCoT t);
      There is no declaration anywhere in the External Core program for :CoT, so
      that's bad.
      I changed the newtype decl syntax so as to include the declaration for the
      coercion axiom introduced by the newtype. Now, it looks like:
        %newtype T a ^ (ZCCoT :: ((T a) :=: (a -> a))) = a -> a;
      And an external typechecker could conceivably typecheck code that uses this.
      The major changes are to MkExternalCore and PprExternalCore (as well as
      ExternalCore, to change the External Core AST.) I also corrected some typos in
      comments in other files.
      Documentation and external tool changes to follow.