1. 18 Jun, 2012 4 commits
  2. 14 Jun, 2012 2 commits
  3. 13 Jun, 2012 2 commits
    • Simon Peyton Jones's avatar
      Simplify the implementation of Implicit Parameters · 5a8ac0f8
      Simon Peyton Jones authored
      This patch re-implements implicit parameters via a class
      with a functional dependency:
      
          class IP (n::Symbol) a | n -> a where
            ip :: a
      
      This definition is in the library module GHC.IP. Notice
      how it use a type-literal, so we can have constraints like
         IP "x" Int
      Now all the functional dependency machinery works right to make
      implicit parameters behave as they should.
      
      Much special-case processing for implicit parameters can be removed
      entirely. One particularly nice thing is not having a dedicated
      "original-name cache" for implicit parameters (the nsNames field of
      NameCache).  But many other cases disappear:
      
        * BasicTypes.IPName
        * IPTyCon constructor in Tycon.TyCon
        * CIPCan constructor  in TcRnTypes.Ct
        * IPPred constructor  in Types.PredTree
      
      Implicit parameters remain special in a few ways:
      
       * Special syntax.  Eg the constraint (IP "x" Int) is parsed
         and printed as (?x::Int).  And we still have local bindings
         for implicit parameters, and occurrences thereof.
      
       * A implicit-parameter binding  (let ?x = True in e) amounts
         to a local instance declaration, which we have not had before.
         It just generates an implication contraint (easy), but when
         going under it we must purge any existing bindings for
         ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
         in TcSimplify
      
       * TcMType.sizePred classifies implicit parameter constraints as size-0,
         as before the change
      
      There are accompanying patches to libraries 'base' and 'haddock'
      
      All the work was done by Iavor Diatchki
      5a8ac0f8
    • Ian Lynagh's avatar
      Follow spelling fixes · 0cba443f
      Ian Lynagh authored
      0cba443f
  4. 12 Jun, 2012 4 commits
  5. 11 Jun, 2012 4 commits
  6. 08 Jun, 2012 2 commits
  7. 07 Jun, 2012 1 commit
  8. 29 May, 2012 2 commits
  9. 28 May, 2012 1 commit
    • Ian Lynagh's avatar
      Add defaultLogActionHPrintDoc to DynFlags · a7b1d219
      Ian Lynagh authored
      We now use this function rather than Outputable.{printSDoc,printErrs}.
      
      Outputable is arguably a better home for the function, but putting it
      in DynFlags should dissuade people from using it inappropriately (in
      particular, nothing other than the default hooks should have stdout
      or stderr hardcoded).
      
      Not exporting it at all would also be an option, but exporting it with
      an ungainly name will make it slightly easier for people who want to
      send output to other Handles for some reason.
      a7b1d219
  10. 22 May, 2012 1 commit
  11. 15 May, 2012 3 commits
    • pcapriotti's avatar
      Simplify the behavior of package db flags. · ba409e30
      pcapriotti authored
      Previously, the `-no-user-package` and `-no-global-package` flags
      affected the "initial" stack only, while `user-package` and
      `global-packages` appended to the end of the stack.
      
      This commit changes the behavior of those flags, so that they are always
      applied to the stack as a whole.
      
      The effect of the GHC_PACKAGE_PATH environment variable has also been
      changed: terminating it with a separator now adds the default package
      dbs (user and global) instead of the initial stack.
      ba409e30
    • pcapriotti's avatar
      Rename package-conf flags to package-db. · ca2debb2
      pcapriotti authored
      Rename package database flags in both GHC and ghc-pkg so that they are
      consistent with Cabal nomenclature.
      
      Add a version check to the build system so that the correct set of
      package db flags are used when the bootstrapping GHC has version < 7.5.
      ca2debb2
    • pcapriotti's avatar
      Add flags to manipulate package db stack (#5977) · 6a831be4
      pcapriotti authored
      Introduce new flags to allow any package database stack to be set up.
      The `-no-user-package-conf` and `-no-global-package-conf` flags remove
      the corresponding package db from the initial stack, while
      `-user-package-conf` and `-global-package-conf` push it back on top of
      the stack.
      6a831be4
  12. 24 Apr, 2012 1 commit
  13. 20 Apr, 2012 1 commit
  14. 11 Apr, 2012 1 commit
  15. 04 Apr, 2012 2 commits
  16. 28 Mar, 2012 1 commit
  17. 24 Mar, 2012 1 commit
  18. 23 Mar, 2012 2 commits
  19. 01 Mar, 2012 1 commit
    • Simon Marlow's avatar
      GHCi: add :seti, for options that apply only at the prompt (#3217) · 2e55760b
      Simon Marlow authored
      GHCi now maintains two DynFlags: one that applies to whole modules
      loaded with :load, and one that applies to things typed at the prompt
      (expressions, statements, declarations, commands).
      
        The :set command modifies both DynFlags.  This is for backwards
        compatibility: users won't notice any difference.
      
        The :seti command applies only to the interactive DynFlags.
      
      Additionally, I made a few changes to ":set" (with no arguments):
      
        * Now it only prints out options that differ from the defaults,
          rather than the whole list.
      
        * There is a new variant, ":set -a" to print out all options (the
          old behaviour).
      
        * It also prints out language options.
      
      e.g.
      
      Prelude> :set
      options currently set: none.
      base language is: Haskell2010
      with the following modifiers:
        -XNoDatatypeContexts
        -XNondecreasingIndentation
      GHCi-specific dynamic flag settings:
      other dynamic, non-language, flag settings:
        -fimplicit-import-qualified
      warning settings:
      
      ":seti" (with no arguments) does the same as ":set", but for the
      interactive options.  It also has the "-a" option.
      
      The interactive DynFlags are kept in the InteractiveContext, and
      copied into the HscEnv at the appropriate points (all in HscMain).
      
      There are some new GHC API operations:
      
      -- | Set the 'DynFlags' used to evaluate interactive expressions.
      setInteractiveDynFlags :: GhcMonad m => DynFlags -> m ()
      
      -- | Get the 'DynFlags' used to evaluate interactive expressions.
      getInteractiveDynFlags :: GhcMonad m => m DynFlags
      
      -- | Sets the program 'DynFlags'.
      setProgramDynFlags :: GhcMonad m => DynFlags -> m [PackageId]
      
      -- | Returns the program 'DynFlags'.
      getProgramDynFlags :: GhcMonad m => m DynFlags
      
      Note I have not completed the whole of the plan outlined in #3217 yet:
      when in the context of a loaded module we don't take the interactive
      DynFlags from that module.  That needs some more refactoring and
      thinking about, because we'll need to save and restore the original
      interactive DynFlags.
      
      This solves the immediate problem that people are having with the new
      flag checking in 7.4.1, because now it is possible to set language
      options in ~/.ghci that do not affect loaded modules and thereby cause
      recompilation.
      2e55760b
  20. 24 Feb, 2012 1 commit
  21. 16 Feb, 2012 1 commit
  22. 14 Feb, 2012 1 commit
  23. 09 Feb, 2012 1 commit