- User Since
- Sep 25 2014, 3:35 AM (230 w, 18 h)
Dec 18 2018
For HsCmd there really is no ambiguity at all! <...> The motivation here is NOT ambiguity but ONLY the desire not to duplicate the grammar of commands and expressions.
Dec 14 2018
@simonpj Can we merge this, unless you have more questions/objections?
Dec 11 2018
Good observation, thanks @goldfire. I couldn't decide if it's an intersection or a union, and now I see it's a union of intersections.
Dec 10 2018
Can you elaborate on this? I don't get it. Commands can't appear in patterns either.
- do and if can appear in HsExpr with HsExpr as subtrees:
checkExpr (FrameIf c a b) = mkHsIf (checkExpr c) (checkExpr a) (checkExpr b) checkExpr (FrameDo ctxt stmts) = mkHsDo ctxt (map checkExprStmt stmts)
How about PTerm (for "parser term")?
Would that not make the data type much smaller? Eg why do you have FrameStmt but not FrameBinds?
Dec 7 2018
A few other stumbling blocks: HsLocalBinds (in HsLet, GRHSs) and Pat (in Match, Stmt).
Found another option how to deal with ExprWithTySig: not using it. I instantiate XXExpr GhcPrePs with
I am confused about this comment; what is dubious about having HsExpr (GhcPass GhcPp), where GhcPp is reserved for Pre-Parsing, as the type of expression-like entities that includes HsPat and HsCmd? Isn't it the same as your ExpPatFrame?
I've added a new Plan G
All of these passes are part of GHC, a single piece of software.
To clarify, option one is:
Dec 6 2018
@simonpj There are two options how I can introduce GhcPrePs:
On the other hand, for Dependent Haskell we will probably have to merge HsExpr and HsType altogether, throughout the entire pipeline. So this bit of motivation is gone.
Dec 5 2018
Dec 4 2018
Remove outdated TODO
Refactor 'checkCommand' to use ExpPatFrame
Rebase, use LExpPatFrame in 'checkValSigLhs'
Dec 3 2018
Oct 29 2018
Oct 28 2018
Oct 27 2018
Can we also add a test case (maybe extend T15264) that the new forall forms trigger the implicit kind variables warning?
I'd be happy to see a test case as I asked before, but overall looks good now.
You marked https://phabricator.haskell.org/D5170#inline-41160 as "Done" but it's not done.
Oct 25 2018
Many functions seem to treat NewPat in a predefined manner instead of recursing into the Pat inside it – I don't see how it could possibly work. Does this rely on the caller to call dL on the pattern? Very fragile, let's not do that.
could you link to the proposal in the description?
Rebase, add proposal link to the commit message
Oct 24 2018
Update comments, rebase
Oct 22 2018
Oct 20 2018
@bgamari The proposal was accepted, would you mind taking another look?
Oct 19 2018
Current documentation talks about GHCi, but we actually face the same issue when using TemplateHaskell because it loads library dynamically, too. Could you mention TemplateHaskell there?
Oct 18 2018
@RyanGlScott I'm fairly sure  is parsed as a HsVar:
I will special-case  in the type-checker.
Oct 17 2018
Great work! I've left a few comments about parsing.
Oct 15 2018
The discussion under https://github.com/ghc-proposals/ghc-proposals/pull/176 indicates that it's far from clear how exactly to proceed here, and it's likely that we'll end up with something different from this Diff, so I'll mark it as abandoned.
I have tested this patch using https://github.com/serokell/trac11042 and it indeed has the intended effect – the error is now a warning:
Oct 13 2018
CI failures are likely unrelated to this change, two tests have "stat too good":
Oct 12 2018
Linux CI has passed: https://circleci.com/gh/ghc/ghc-diffs/457
On the other hand, one could argue that even failing test cases should pass -Wcompat's scrutiny.
Update test cases
Oct 11 2018
This change is not yet accepted by the GHC Steering Committee, but I prepared a patch for the case it gets accepted.
Oct 10 2018
Workaround for operator sections
Oct 9 2018
I tried to build it and test it but it doesn't build
I tried to build it and test it but it doesn't build
@osa1 I disagree with your analysis. With this patch, the examples you gave should parse as before, and no action from the users is needed in these cases. The change is that when the annotation is used after an infix operator, it applies only to the RHS of this operator. And in your examples there aren't even any operators.
I updated the migration guide as requested: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.8?action=diff&version=5
Oct 8 2018
The CI failures do not seem related to the change:
Oct 5 2018
I'm undecided how to proceed here because it appears the invariant about the type being closed is violated in current code.
Oct 4 2018
Bump Cabal submodule
Oct 3 2018
@RyanGlScott Sure, I can apply the same approach to terms, but I would prefer to do it in a separate Diff. For now I added Note [isFunLhs vs mergeDataCon] that documents the difference in detail.
That has been fixed (and for the better I think!). Consider the following GHCi session
I also added two entries to docs/users_guide/8.8.1-notes.rst.
Documentation, test cases for error messages, rebase
Aha. That's a much stronger reason.
why it differs from the design for expressions?
Oct 1 2018
Documentation and error messages
Documentation and rebase
Sep 25 2018
Created https://phabricator.haskell.org/D5180 with a proper fix.
Aug 27 2018
The downside to @int-index's approach is that it requires adding a lot of extension fields
Aug 22 2018
I advocate the less ambitious version, which still lets you do the Trac Trac #12088 stuff, doesn't it?
Aug 21 2018
Aug 17 2018
@RyanGlScott Here's a test case: