> On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli <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
