Tue, Apr 2
Mar 18 2019
Sep 2 2018
Great, thanks for taking a look @RyanGlScott !
Sep 1 2018
@RyanGlScott Hey! Sorry for the delay. Finally found some cycles to iterate on this. I've just added one line to the release notes, I figure may as well keep it concise, since users can consult the template-haskell changelog / API.
- Add release note for TH support for implicit params + mdo
Aug 21 2018
Yep, this is on my TODOs - sorry for the delay but got busy with other
things. Hopefully will have a spare cycle soon
Jul 28 2018
- Shorter name for ghc-in-ghci output dir
Nevermind, with many substantial changes to GHC's code, -fobject-code is needed to for it to load. So, this change should definitely be made to the scripts.
Ah, indeed, it looks like when you run ghci without -fobject-code, but there are objects present from a prior run with -fobject-code, then it works. This is actually rather nice, because GHCi is much faster when generating bytecode instead of object code.
Jul 27 2018
Woohoo!! Thanks for merging, @bgamari!
Awesome, thanks for merging @bgamari ! Note that for this script to work properly, https://phabricator.haskell.org/D4986 needs to be merged as well. In the meantime one can remove -ighc and :load Main, and it should work at least for loading the compiler code, but you won't be able to run GHC inside of GHCi without the changes in 4986.
Jul 26 2018
- Remove -fobject-code as it is not always wanted
Jul 25 2018
Awesome, thanks a bunch for the guidance! I will work on this soon,
hopefully sometime tomorrow
I can add such a test. Where should a test like that go?
Lol.. That's what I get for trying to do too many things at once late at night.
Fix another 2 AM typo...
I believe that should fix it, though I must admit I haven't run it through a full make yet. Perhaps I can leave that up to harbormaster? Not familiar with whether I can rely on CI or not.
Update spelling of NoImplicitPrelude
Ah good catch! That's what I get for only testing this in ghci ;)
Maybe I'm not seeing it because I'm tired, but how come you needed to add all those NoImplicitPreludes and import Preludes ?
Add default-extensions: NoImplicitPrelude to some cabal files, remove use of pragmas
Jul 23 2018
Jul 19 2018
Fix a --restart path typo
- Add .ghcid file - https://github.com/ndmitchell/ghcid/issues/140
@goldfire Ah, right you are! Not sure quite why I didn't previously see something as obvious as that, I guess I must have forgotten that the solution there no longer encountered the error during conversion.
- Add a test for addTopDecls not panicing
I have pushed an update to this which modifies a few less of the THNames, and entirely avoids modifying compiler/prelude/PrelNames.hs. I found that I needed to do a clean make when switching to this branch. It would work, but it's pretty ugly to break incrementality like that. That not working may indicate a deeper issue, but that is out of scope for this diff.
Avoid changing PrelNames ids
https://phabricator.haskell.org/D4909 is a simpler fix for this. While this is more efficient, not sure if the complexity is worth its weight, so abandoning the revision.
Move top level scripts into utils subdir + documentation improvements + remove ghci-start
I have split off D4986 and D4987 from this diff so now all this does is add files. Only the former is a dependency of this change. I also removed the ghci-start script, since it wasn't really necessary, and renamed ghci-load to utils/ghc-in-ghci/run.sh.
Remove unnecessary change to System.Directory import in SysTools.BaseDir
I think the point of the Makefile approach would be to generate the necessary settings.ghci file automatically from other dependency information. This will probably be easier once hadrian is merged.
Jul 7 2018
- Remove the last remnants of Makefile changes
@bgamari Please take a look. I've switched it over to using _GHC_TOP_DIR + top level shell scripts instead of Makefile targets. This seems better than how it was.
- Add a comment in findTopDir about _GHC_TOP_DIR env var
- _GHC_TOP_DIR to specify top dir + use scripts instead of makefile
Glad I gave this approach a whirl, I think this is much cleaner 👍
Instead of undoing ApplicativeDo in DsMeta, don't apply the transform within TH brackets
Thanks @goldfire ! Yeah, I'm pretty stoked about it. As mentioned elsewhere, this makes development far more enjoyable. I'm often getting something like a 10 or 15 second iteration time between saving a file, reloading the compiler, and getting a nested GHCi with which to try out the new behavior.
That's a compelling idea. To be honest, though, I'm not sure of the ramifications of that decision, not being familiar enough with ApplicativeDo. Are there programs that would type-check that shouldn't? Programs that are rejected that shouldn't?
Jul 6 2018
Thanks for the feedback and diff approval!
Jul 5 2018
I have been doing some unrelated work using TH recently, and this unbound var stuff is quite a deviation from how TH used to work.
Jul 4 2018
I've realized that we'll also want a way to query a list of names for top level definitions from before the current splice. This is quite different from reifying exports, but kinda similar. The current situation with reifyModule having different semantics for thisModule vs others seems quite analogous. I propose:
I'm unclear on the design here. Why do we need lookupImportedModule? It looks like, currently, the TH client is expected to build a Module directly by using the Module constructor. Why does this change?
- Add explicit import list and tycon hiding to test for T10391
- Add explicit import list and tycon hiding to test for T10391
- Removed implementation of lookupImportedModule
Jul 3 2018
@goldfire Welcome, thanks for reviewing! I don't think that this suggests we should have a better AST for TH, because I don't think ApplicativeDo structures should be visible to TH. The logic here is modeled closely after the ppr logic.
@goldfire Thanks for reviewing!
Thanks for reviewing, Richard! I think I have made a change which addresses your inline comment.
- Better error message for addTopDecls conversion errors
- Add a comment clarifying use of vcName
@sighingnow Ah, good catch! Not sure how that snuck in there. Some notes while I was poking around the code trying to figure out how to easily add some functions like parseExp :: String -> Q Exp :)
Remove unintentionally added file "th-parse-notes.md"
Jul 2 2018
@sighingnow Thanks for reviewing. Please take a look at https://ghc.haskell.org/trac/ghc/ticket/9693 . Reproducing this problem requires modifying the code and reloading into ghci. Note that the symptoms no longer involves panic-ing. However, the reload of modified code behaves differently than a fresh load.
Update commit message
One thing to note is that to get this expected output, https://phabricator.haskell.org/D4914 needs to be merged first.
@bgamari "qAddTopDecls" isn't an implementation detail, since it's exposed by the TH API as a method of the Quasi typeclass. addTopDecls is just a wrapper that forces the monad to be Q.
- Improve message text when qAddTopDecls encounters a conversion error
Having a GHC_TOP_DIR environment variable makes sense. Would it be useful otherwise? Was the leading underscore intentional?
@bgamari Thanks for reviewing! I've updated it with some changes that I've found convenient. It now sets "args" such that running "main" will default to running a nested GHCi with a script that changes the prompt to indicate that it is the inner GHCi. Otherwise I found it easy to forget if you're in the inner or outer GHC.
- Have "make ghci-load" default args so that "main" runs an inner ghci
- Add documentation in the Makefile and switch to make ARGS parameter
Jul 1 2018
Jun 30 2018
Jun 29 2018
It may be worthwhile to attempt to leave the PrelNames ids unchanged. When switching to and from this branch I'm getting errors like
@RyanGlScott Thanks for reviewing! I've added haddocks for the Stmt constructors.
Rebase onto master rather than basing off my not-yet-merged changes
Fix ID overlap issue by adding 100 to some PrelNames
I'm abandoning this revision for now, because I think that putting some fine-grained catching within findValidHoleFits would be better. Here's some discussion on trac for context: https://ghc.haskell.org/trac/ghc/ticket/15321#comment:4
Note that for convenience, I had my other patches merged on that branch - https://phabricator.haskell.org/D1979 and https://phabricator.haskell.org/D4904 . Not sure how this interacts with phabricator.
Decided to include module locals when in RunSplice stage. No use of this currently I think, but I think this choice makes more sense
Jun 28 2018
Remove "reifyPred = reifyType" and just use "reifyType" in "reifyCxt"
Hey guys, it's been a while. Really sorry for abandoning this and not iterating on it until now. I finally made the time and prioritization to get back to this. A big part of it was the appeal of being able to use GHCi for development of GHC - https://phabricator.haskell.org/D4904 - I find it hard to work on big Haskell projects without that.
- Rebased atop ~2 years worth of changes
Note that there is some prior conversation about this change on github - https://github.com/ghc/ghc/pull/154 - but this differential supersedes that PR.
- Better name for the top_dir workaround + comment
- Use "ghci-load" and "ghci-start" targets instead of "load-ghci" and "run-ghci"
Apr 27 2016
Pinging @goldfire , I realize you're busy. It's fine to get this in post 8.0. How's it look? I believe I've addressed your feedback adequately. Perhaps other than that one spot where I do sort_by_loc, blindly emulating neighboring code that does something very similar.