Alfredo also replied to this pointing his embedding plan. I also prefer
that, because I really wish TH didn't smear together the phases so much.
Moreover, I hope with
- GHC proposals
https://github.com/ghc-proposals/ghc-proposals/pull/412 /
https://github.com/ghc-proposals/ghc-proposals/pull/243
- The parallelism work currently be planned in
https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output
we might actually have an opportunity/extra motivation to do that.
Splices and quotes will still induce intricate inter-phase dependencies,
but I hope that could be mediated by the driver rather than just baked
into each phase.
(One final step would be the "stuck macros" technique of
https://www.youtube.com/watch?v=nUvKoG_V_U0 /
https://github.com/gelisam/klister, where TH splices would be able to
making "blocking queries" of the the compiler in ways that induce more
of these fine-grained dependencies.)
Anyways, while we could also do a "RnTsDsError" and split later, I hope
Alfredo's alternative of embedding won't be too much harder and prepare
us for these exciting areas of exploration.
John
On 3/30/21 10:14 AM, Richard Eisenberg wrote:
On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli
<alfredo.dinap...@gmail.com <mailto:alfredo.dinap...@gmail.com>> wrote:
I'll explore the idea of adding a second IORef.
Renaming/type-checking is already mutually recursive. (The renamer
must call the type-checker in order to rename -- that is, evaluate --
untyped splices. I actually can't recall why the type-checker needs to
call the renamer.) So we will have a TcRnError. Now we see that the
desugarer ends up mixed in, too. We could proceed how Alfredo
suggests, by adding a second IORef. Or we could just make TcRnDsError
(maybe renaming that).
What's the disadvantage? Clients will have to potentially know about
all the different error forms with either approach (that is, using my
combined type or using multiple IORefs). The big advantage to
separating is maybe module dependencies? But my guess is that the
dependencies won't be an issue here, due to the fact that these
components are already leaning on each other. Maybe the advantage is
just in having smaller types? Maybe.
I don't have a great sense as to what to do here, but I would want a
clear reason that e.g. the TcRn monad would have two IORefs, while
other monads will work with GhcMessage (instead of a whole bunch of
IORefs).
Richard
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
