- User Since
- Sep 25 2014, 3:35 AM (268 w, 5 d)
Wed, Oct 30
Oct 12 2019
Oct 8 2019
Sep 30 2019
Sep 26 2019
Aug 30 2019
Jul 26 2019
Jul 24 2019
Jul 19 2019
Jul 15 2019
Jul 4 2019
Jun 10 2019
May 29 2019
May 8 2019
May 6 2019
Apr 25 2019
Apr 22 2019
Apr 19 2019
Apr 2 2019
Mar 9 2019
Mar 4 2019
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