1. 13 Aug, 2020 5 commits
  2. 12 Aug, 2020 6 commits
  3. 11 Aug, 2020 3 commits
  4. 10 Aug, 2020 2 commits
  5. 09 Aug, 2020 1 commit
  6. 08 Aug, 2020 2 commits
  7. 07 Aug, 2020 7 commits
  8. 06 Aug, 2020 7 commits
    • Takenobu Tani's avatar
      users-guide: Rename 8.12 to 9.0 · 9570c212
      Takenobu Tani authored
      GHC 8.12.1 has been renamed to GHC 9.0.1.
      See also:
      [skip ci]
    • Sylvain Henry's avatar
      Use a type alias for Ways · 63348155
      Sylvain Henry authored
    • Richard Eisenberg's avatar
      Fail eagerly on a lev-poly datacon arg · d2a43225
      Richard Eisenberg authored
      Close #18534.
      See commentary in the patch.
    • Vladislav Zavialov's avatar
      Fix visible forall in ppr_ty (#18522) · 0ddb4384
      Vladislav Zavialov authored
      Before this patch, this type:
        T :: forall k -> (k ~ k) => forall j -> k -> j -> Type
      was printed incorrectly as:
        T :: forall k j -> (k ~ k) => k -> j -> Type
    • Vladislav Zavialov's avatar
      Fix debug_ppr_ty ForAllTy (#18522) · 826d07db
      Vladislav Zavialov authored
      Before this change, GHC would
      pretty-print   forall k. forall a -> ()
                as   forall @k a. ()
      which isn't even valid Haskell.
    • Vladislav Zavialov's avatar
      Clean up the story around runPV/runECP_P/runECP_PV · 6770e199
      Vladislav Zavialov authored
      This patch started as a small documentation change, an attempt to make
      Note [Parser-Validator] and Note [Ambiguous syntactic categories]
      more clear and up-to-date.
      But it turned out that runECP_P/runECP_PV are weakly motivated,
      and it's easier to remove them than to find a good rationale/explanation
      for their existence.
      As the result, there's a bit of refactoring in addition to
      a documentation update.
    • Vladislav Zavialov's avatar
      Grammar for types and data/newtype constructors · 686e06c5
      Vladislav Zavialov authored
      Before this patch, we parsed types into a reversed sequence
      of operators and operands. For example, (F x y + G a b * X)
      would be parsed as [X, *, b, a, G, +, y, x, F],
      using a simple grammar:
      	  : tyapp
      	  | tyapps tyapp
      	  : atype
      	  | PREFIX_AT atype
      	  | tyop
      	  | unpackedness
      Then we used a hand-written state machine to assemble this
       either into a type,        using 'mergeOps',
           or into a constructor, using 'mergeDataCon'.
      This is due to a syntactic ambiguity:
      	data T1 a =          MkT1 a
      	data T2 a = Ord a => MkT2 a
      In T1, what follows after the = sign is a data/newtype constructor
      declaration. However, in T2, what follows is a type (of kind
      Constraint). We don't know which of the two we are parsing until we
      encounter =>, and we cannot check for => without unlimited lookahead.
      This poses a few issues when it comes to e.g. infix operators:
      	data I1 = Int :+ Bool :+ Char          -- bad
      	data I2 = Int :+ Bool :+ Char => MkI2  -- fine
      By this issue alone we are forced into parsing into an intermediate
      representation and doing a separate validation pass.
      However, should that intermediate representation be as low-level as a
      flat sequence of operators and operands?
      Before GHC Proposal #229, the answer was Yes, due to some particularly
      nasty corner cases:
      	data T = ! A :+ ! B          -- used to be fine, hard to parse
      	data T = ! A :+ ! B => MkT   -- bad
      However, now the answer is No, as this corner case is gone:
      	data T = ! A :+ ! B          -- bad
      	data T = ! A :+ ! B => MkT   -- bad
      This means we can write a proper grammar for types, overloading it in
      the DisambECP style, see Note [Ambiguous syntactic categories].
      With this patch, we introduce a new class, DisambTD. Just like
      DisambECP is used to disambiguate between expressions, commands, and patterns,
      DisambTD  is used to disambiguate between types and data/newtype constructors.
      This way, we get a proper, declarative grammar for constructors and
      	  : ftype
      	  | ftype tyop infixtype
      	  | unpackedness infixtype
      	  : atype
      	  | tyop
      	  | ftype tyarg
      	  | ftype PREFIX_AT tyarg
      	  : atype
      	  | unpackedness atype
      And having a grammar for types means we are a step closer to using a
      single grammar for types and expressions.
  9. 05 Aug, 2020 7 commits