1. 11 Mar, 2012 1 commit
  2. 02 Mar, 2012 1 commit
  3. 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
  4. 16 Feb, 2012 1 commit
  5. 14 Feb, 2012 2 commits
  6. 13 Feb, 2012 2 commits
  7. 10 Feb, 2012 2 commits
  8. 07 Feb, 2012 1 commit
  9. 26 Jan, 2012 1 commit
  10. 24 Jan, 2012 1 commit
  11. 03 Jan, 2012 2 commits
    • Simon Marlow's avatar
      Fix minor bug introduced in e7e771d1 · aa1114ed
      Simon Marlow authored
      aa1114ed
    • 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
  12. 23 Dec, 2011 3 commits
  13. 20 Dec, 2011 2 commits
  14. 04 Nov, 2011 1 commit
  15. 24 Oct, 2011 1 commit
  16. 17 Oct, 2011 1 commit
  17. 06 Oct, 2011 1 commit
  18. 23 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Implement GHCi command :kind! which normalises its type · f3c7ed72
      Simon Peyton Jones authored
         type family F a
         type instance F Int = Bool
         type instance F Bool = Char
      
      In GHCi
         *TF> :kind (F Int, F Bool)
         (F Int, F Bool) :: *
         *TF> :kind! F Int
         (F Int, F Bool) :: *
         = (Bool, Char)
      
      We could call it ":normalise" but it seemed quite nice to have an
      eager version of :kind
      f3c7ed72
  19. 21 Sep, 2011 3 commits
    • Simon Marlow's avatar
      fc80c870
    • 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
    • Simon Marlow's avatar
      In :load, call GHC.guessTarget on the new targets before unloading · 9de6f19e
      Simon Marlow authored
      Fixes this problem:
      
      Prelude> :l foo
      target `foo' is not a module name or a source file
      >
      9de6f19e
  20. 01 Sep, 2011 1 commit
  21. 26 Aug, 2011 2 commits
    • Simon Marlow's avatar
      fix warning · 3a6120a2
      Simon Marlow authored
      3a6120a2
    • Simon Marlow's avatar
      Clean up the handling of the import and :module commands in GHCi · 79d6745f
      Simon Marlow authored
      Previously we remembered the whole history of commands and replayed
      them on every :load/:reload, which lead to some non-linear performance
      characteristics (#5317).  The handling of the implicit Prelude import
      and the implicit imports of recently loaded modules was also
      complicated and wrong in various obscure ways.
      
      The Prelude import works just like the implicit Prelude import in a
      Haskell module: it can be overriden with an explicit Prelude
      import.
      
      I have added a new ":show imports" command to show which imports are
      currently in force.
      
      Prelude> :show imports
      import Prelude -- implicit
      Prelude> import Prelude ()
      Prelude> :show imports
      import Prelude ()
      Prelude> map
      
      <interactive>:0:1: Not in scope: `map'
      Prelude>
      
      Full documentation in the User's Guide.
      
      There are various other little tweaks and improvements, such as when a
      module is imported with 'as', we now show the 'as' name in the prompt
      rather than the original name.
      79d6745f
  22. 22 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      In :browse, always print output in the *current* context · cd3d6f88
      Simon Peyton Jones authored
      Previously :browse M (without !) printed output relative to
      a context that was neither the current one, nor the top-level
      context of M, but rather that established
      by
           import Prelude
           import M
      This was pretty confusing, so Simon and I agreed to use
      a simple, uniform rule: output in GHC is always relative
      to the current context.
      cd3d6f88
  23. 19 Aug, 2011 3 commits
  24. 02 Aug, 2011 2 commits
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
      
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
      
        * Used record notation consistently for ImportDecl
      35d213ab
  25. 21 Jul, 2011 1 commit
  26. 12 Jul, 2011 1 commit
  27. 30 Jun, 2011 1 commit