Why TcLclEnv and DsGblEnv need to store the same IORef for errors?
john.ericson at obsidian.systems
Wed Mar 31 03:44:25 UTC 2021
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
- The parallelism work currently be planned in
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://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.
On 3/30/21 10:14 AM, Richard Eisenberg wrote:
>> On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli
>> <alfredo.dinapoli at gmail.com <mailto:alfredo.dinapoli at 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
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs