#9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:21 goldfire]:
{{{ f = g 5 g = $(...) }}}
The suggestion to process declarations that do not contain a splice before declarations that do fails here.
Instead, we recognize that `f` and `g` are in a mutually recursive group and process them together. `g` cannot reify `f`. Note that comment:15 says
Yes, indeed, it is very similar to my example at the top of comment:20, but I felt it wouldn't be easy to handle. Perhaps it is... that only already-processed declarations (that is, not in the same mutually recursive group) are available. Are `f` and `g` mutually recursive? Since you explicitly say `g` ''cannot'' reify `f` - does `f` therefore just depend on `g`? What about in: {{{ f = e $(...) c = $(...) e = c ... d = $(...) a = ... b ... b = ... a ... }}} I think an processing order: `(a b) < (c d) < e < f` could work: 1. `a, b` are in scope to reify/call for `c`, 1. `c` is ''not'' in scope to reify/call for `d` (we cannot in general determine what `d` `reify`s so cannot order the splices - as per comment:19) 1. `a, b, c, d` are in scope to reify/call in `e`, there is a data dependency between `e` and `c` (and thus implicitly `d`): `e` is ordered ''after'' `c` 1. `a, b, c, d, e` are in scope to reify/call in `f` since there is a data dependency between `f` and `e`: `f` is ordered ''after'' `e`.
It does strike me (inspired by comment:16) that with all this toposorting going on, we may be able to avoid having top-level splices break the file up into declaration groups. The current behavior seems something like a feeble attempt at a toposort, anyway.
Indeed, I think that would be nice for a consistent story. However, how do you order top-level declarations in the toposort? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9813#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler