Why TcLclEnv and DsGblEnv need to store the same IORef for errors?

[John Ericson]

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.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 
> IORefs).
>
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210330/d6c5a393/attachment.html>