1. 09 Feb, 2014 1 commit
  2. 26 Jan, 2014 1 commit
  3. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      
      The rundown is this:
      
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
      
        * Unidirectional patterns are declared like thus:
      
              pattern P x <- x:_
      
          The synonym 'P' may only occur in a pattern context:
      
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
      
        * Bidirectional patterns are declared like thus:
      
              pattern P x y = [x, y]
      
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
      
              bar :: Int -> [Int]
              bar x = P x 10
      
        * Patterns can't yet have their own type signatures; signatures are inferred.
      
        * Pattern synonyms may not be recursive, c.f. type synonyms.
      
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
      
              module Foo (pattern Bar) where ...
      
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
      
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
      
              pattern P x y <- [x, y]
      
              f (P True True) = True
              f _             = False
      
              g [True, True] = True
              g _            = False
      
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      
      For more information, see the wiki:
      
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/ImplementationReviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  4. 15 Jan, 2014 2 commits
  5. 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
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          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
          defined.
      
          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.
      73c08ab1
  6. 08 Jan, 2014 1 commit
  7. 03 Jan, 2014 2 commits
    • Simon Peyton Jones's avatar
      Refactor the way shadowing in handled in GHCi · 5dffb4ac
      Simon Peyton Jones authored
      If you say
        ghci> import Foo( T )
        ghci> data T = MkT
        ghci> data T = XXX
      then the second 'data T' should shadow the first.  But the qualified
      Foo.T should still be available.  We really weren't handling this
      correctly at all, resulting in Trac #8639 and #8628 among others
      
      This patch:
      
      * Add RdrName.extendGlobalRdrEnv, which does shadowing properly
      
      * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
        to use the new function
      
      * Change RnNames.extendGobalRdrEnvRn to use the new function
      
      * Move gresFrom Avails into RdrName
      * Better pprGlobalRdrEnv function in RdrName
      5dffb4ac
    • Simon Peyton Jones's avatar
      Improve error message when using qualified names in GHCi · e60a841b
      Simon Peyton Jones authored
      When you say
        ghci> :i Foo.x
      GHCi tries to find module Foo and get 'x' from it.  But
      if Foo doesn't exist we don't want to say:
        Attempting to use module ‛Foo’ which is not loaded
      
      This is a bit confusing. Rather we just want to say that
      Foo.x is not in scope.
      e60a841b
  8. 27 Dec, 2013 2 commits
    • Edsko de Vries's avatar
      Add hook for splicing in renamer · df2dd64d
      Edsko de Vries authored
      With the recent modifications to the TH infrastructure, many splices are now
      expanded in the renamer rather than the typechecker. This means that tools
      which inspect the renamed tree don't get to see the original splices. Added a
      new hook which gets called before such a splice gets expanded, analogous to the
      runQuasiQuoteHook.
      df2dd64d
    • eir@cis.upenn.edu's avatar
      Fix #8607. · e4afeedc
      eir@cis.upenn.edu authored
      The solution (after many false starts) is to change the behavior of
      hsLTyClDeclBinders. The idea is that the locations of the names that
      the parser generates should really be the names' locations, unlike
      what was done in 17457791... But, when the renamer is creating Names
      from the RdrNames, the locations stored in the Names should be the
      declarations' locations. This is now achieved in hsLTyClDeclBinders,
      which returns [Located name], but the location is that of the
      *declaration*, not the name itself.
      e4afeedc
  9. 05 Dec, 2013 1 commit
  10. 27 Nov, 2013 1 commit
  11. 25 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      Another raft of Template Haskell clean-up · 51deeb0d
      Simon Peyton Jones authored
      The handling of typed and untyped brackets was extremely convoluted,
      partly because of the evolutionary history.  I've tidied it all up.
      
      See Note [How brackets and nested splices are handled] in TcSplice
      for the full story
      
      Main changes:
      
       * Untyped brackets: after the renamer, HsRnBracketOut carries
         PendingRnSplices for splices in untyped brackets.  In the
         typechecker, these pending splices are typechecked quite
         straigtforwardly, with no ps_var nonsense.
      
       * Typed brackets: after the renamer typed brackest still look
         like HsBracket. The type checker does the ps_var thing.
      
       * In TcRnTypes.ThStage, the Brack constructor, we distinguish
         the renaming from typehecking pending-stuff.  Much more
         perspicuous!
      
       * The "typed" flag is in HsSpliceE, not in HsSplice, because
         only expressions can be typed.  Patterns, types, declarations
         cannot.
      
      There is further improvement to be done to make the handling of
      declaration splices more uniform.
      51deeb0d
  12. 22 Nov, 2013 2 commits
    • Simon Peyton Jones's avatar
      ea49c015
    • Simon Peyton Jones's avatar
      A raft of changes driven by Trac #8540 · 78814882
      Simon Peyton Jones authored
      The root cause of #8450 is that the new Template Haskell story, with
      the renamer doing more of the work of Template Haskell, wasn't dealing
      correctly with the keepAlive problem.  Consider
          g = ..blah...
          f = [| g |]
      Then f's RHS refers to g's name but not to g, so g was being discarded
      as dead code.
      
      Fixing this sucked me into a deep swamp of understanding how all the moving
      parts of hte new Template Haskell fit together, leading to a large collection
      of related changes and better documentation.  Specifically:
      
      * Instead of putting the TH level of a binder in the LocalRdrEnv, there
        is now a separate field
            tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel)
        in the TcLclEnv, which records for each binder
           a) whether it is syntactically a top-level binder or not
           b) its TH level
        This deals uniformly with top-level and non-top-level binders, which was
        previously dealt with via greviously-delicate meddling with Internal and
        External Names.  Much better.
      
      * As a result I could remove the tct_level field of ATcId.
      
      * There are consequential changes in TcEnv too, which must also extend the
        level bindings.  Again, more clarity.
      
        I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used
        during kind inference, for (AThing kind) and APromotionErr; and that is
        relevant to whether we want to extend the tcl_th_bndrs field (no).
      
      * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the
        qual_gre code which said "Seems like 5 times as much work as it deserves!".
        Instead, RdrName.pickGREs makes the Internal names shadow External ones.
      
      * I moved the checkThLocalName cross-stage test to finishHsVar; previously
        we weren't doing the test at all in the OpApp case!
      
      * Quite a few changes (shortening the code) in the cross-stage checking code
        in TcExpr and RnSplice, notably to move the keepAlive call to the renamer
      
      One leftover piece:
      
      * In TcEnv I removed tcExtendGhciEnv and refactored
        tcExtendGlobalTyVars; this is really related to the next commit, but
        it was too hard to disentangle.
      78814882
  13. 06 Nov, 2013 1 commit
  14. 05 Nov, 2013 1 commit
  15. 02 Nov, 2013 1 commit
  16. 29 Oct, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Fix Trac #8485. · 9366e019
      eir@cis.upenn.edu authored
      The problem was that the renamer treated role annotations by looking
      up the annotated type in the module being compiled. If this check
      succeeded, it was assumed that the annotated type was being compiled
      at the same time. But this assumption is false! In GHCi (and Template
      Haskell), sometimes compilation within one module can be staged. So,
      now there is a more intricate check for orphan role annotations. This
      also has the benefit of producing better error messages.
      9366e019
  17. 23 Oct, 2013 1 commit
    • Simon Peyton Jones's avatar
      Fix Trac #8448 · dc9961f9
      Simon Peyton Jones authored
      We weren't dealing with built-in syntax; data constructors
      that are built-in syntax (only [] actually) don't appear
      in the GlobalRdrEnv
      dc9961f9
  18. 12 Oct, 2013 1 commit
  19. 04 Oct, 2013 10 commits
  20. 01 Oct, 2013 1 commit
  21. 28 Sep, 2013 1 commit
  22. 27 Sep, 2013 1 commit
  23. 23 Sep, 2013 1 commit
  24. 18 Sep, 2013 2 commits
    • twanvl's avatar
      Implement checkable "minimal complete definitions" (#7633) · bd42c9df
      twanvl authored
      This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible
      minimal complete definitions for a class. The body of the pragma is a
      boolean formula of names.
      
      The old warning for missing methods is replaced with this new one.
      
      Note: The interface file format is changed to store the minimal complete
      definition.
      Authored-by: twanvl's avatarTwan van Laarhoven <twanvl@gmail.com>
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      bd42c9df
    • eir@cis.upenn.edu's avatar
      Change role annotation syntax. · f4046b50
      eir@cis.upenn.edu authored
      This fixes bugs #8185, #8234, and #8246. The new syntax is explained
      in the comments to #8185, appears in the "Roles" subsection of the
      manual, and on the [wiki:Roles] wiki page.
      
      This change also removes the ability for a role annotation on type
      synonyms, as noted in #8234.
      f4046b50
  25. 14 Sep, 2013 1 commit
  26. 11 Sep, 2013 1 commit