User Details
- User Since
- Jul 15 2014, 12:40 PM (282 w, 4 d)
Jul 8 2016
Oct 12 2015
My conclusion was that support for the extension was very mixed, and that I
do not think the extension makes sense without overall approval from the
community. I am not planning on pushing this any further.
Sep 6 2015
@goldfire: I would actually prefer the pretty printer work properly. I added that because I didn't realize it was working wrong. It used to say something like, "there is an error in the do block below, do you want Argument Do". But then there were parens, so it didn't make sense, because GHC had fixed the error when pretty printing, so the user would be confused, because the shown code was not what they typed, and the shown code was actually NOT an error. So if the pretty printer is fixed, I'll change the error message back to what it was originally (that is what I would prefer).
Sep 5 2015
Hooray, it passes ./validate now.
- Add strictness in parser to avoid allocation
I got validation errors in parsing001. This seems to be a performance test. I don't think my parser changes in any way should change the parsing of the parsing001 test... any ideas as to why this is failing? (I restarted the build to see if its intermittent...)
- Fix tests for lambda case and error messages
- Parse lambdas without dollar sign
- Fix test that detects ghc-only extensions
@nomeata: Here's some info on the $ hack from StackOverflow.
I've fixed the validation failure for now (and will fix more if they come), but I think the real question is not whether the code is correct right now, but whether we actually want an extension like this...
- ArgumentDo only applies to do blocks, not list comprehensions, etc
Jul 27 2015
It is unclear whether this feature is necessary or whether this would be the right way to implement it if it is necessary, so this diff is being abandoned.
Check out the GHC trac page. There was more discussion there – it seemed like there were alternatives to this that removed the need for this patch.
Jun 30 2015
There is no reason for parseFullStmt to exist. I am in favor of getting rid of it. Including it was a mistake, oops.
Aug 22 2014
Should I added a test for this?