[Git][ghc/ghc][master] 7 commits: Grammar for types and data/newtype constructors

Thu Aug 6 23:47:14 UTC 2020

Ben Gamari pushed to branch master at Glasgow Haskell Compiler / GHC

Commits:
686e06c5 by Vladislav Zavialov at 2020-08-06T13:34:05-04:00
Grammar for types and data/newtype constructors

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:

	tyapps
	  : tyapp
	  | tyapps tyapp

	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
types:

	infixtype
	  : ftype
	  | ftype tyop infixtype
	  | unpackedness infixtype

	ftype
	  : atype
	  | tyop
	  | ftype tyarg
	  | ftype PREFIX_AT tyarg

	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.

- - - - -
6770e199 by Vladislav Zavialov at 2020-08-06T13:34:05-04:00
Clean up the story around runPV/runECP_P/runECP_PV

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.

- - - - -
826d07db by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix debug_ppr_ty ForAllTy (#18522)

Before this change, GHC would
pretty-print   forall k. forall a -> ()
          as   forall @k a. ()
which isn't even valid Haskell.

- - - - -
0ddb4384 by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix visible forall in ppr_ty (#18522)

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

- - - - -
d2a43225 by Richard Eisenberg at 2020-08-06T13:34:06-04:00
Fail eagerly on a lev-poly datacon arg

Close #18534.

See commentary in the patch.

- - - - -
63348155 by Sylvain Henry at 2020-08-06T13:34:08-04:00
Use a type alias for Ways

- - - - -
9570c212 by Takenobu Tani at 2020-08-06T19:46:46-04:00
users-guide: Rename 8.12 to 9.0

GHC 8.12.1 has been renamed to GHC 9.0.1.

See also:
  https://mail.haskell.org/pipermail/ghc-devs/2020-July/019083.html

[skip ci]

- - - - -

30 changed files:

- compiler/GHC/Core/TyCo/Ppr.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Platform/Profile.hs
- compiler/GHC/Platform/Ways.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Unit/State.hs
- docs/users_guide/8.12.1-notes.rst → docs/users_guide/9.0.1-notes.rst
- docs/users_guide/exts/lambda_case.rst
- docs/users_guide/exts/lexical_negation.rst
- docs/users_guide/exts/linear_types.rst
- docs/users_guide/exts/negative_literals.rst
- docs/users_guide/exts/qualified_do.rst
- docs/users_guide/release-notes.rst
- docs/users_guide/using-warnings.rst
- + testsuite/tests/ghc-api/T18522-dbg-ppr.hs
- + testsuite/tests/ghc-api/T18522-dbg-ppr.stdout
- testsuite/tests/ghc-api/all.T
- testsuite/tests/parser/should_fail/T12045d.stderr
- testsuite/tests/parser/should_fail/strictnessDataCon_B.stderr
- testsuite/tests/parser/should_fail/typeops_A.stderr
- testsuite/tests/parser/should_fail/typeops_C.stderr
- testsuite/tests/parser/should_fail/unpack_empty_type.stderr
- testsuite/tests/parser/should_fail/unpack_inside_type.stderr
- + testsuite/tests/polykinds/T18522-ppr.script
- + testsuite/tests/polykinds/T18522-ppr.stdout
- testsuite/tests/polykinds/all.T
- + testsuite/tests/typecheck/should_fail/T18534.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/fbcb886d503dd7aaebc4c40e59615068b3fd0bd7...9570c21295a2b4a1d1e40939869124f0b9b9bf91

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/fbcb886d503dd7aaebc4c40e59615068b3fd0bd7...9570c21295a2b4a1d1e40939869124f0b9b9bf91
You're receiving this email because of your account on gitlab.haskell.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20200806/bf614214/attachment.html>