#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 goldfire): Replying to [comment:22 owst]:
Are `f` and `g` mutually recursive? Since you explicitly say `g` ''cannot'' reify `f` - does `f` therefore just depend on `g`?
We declare that they are. That's what's meant by "anything with a splice depends on anything else". It's true that the splice can't do much reify `f`, but it can certainly produce code which calls `f`.
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:
I don't think this would quite work. What if `c` calls `f`? That is, `c = $(varE (mkName (['a'..] !! 5 : [])))`. We don't know without running the splice, so we say that anything with a splice depends on anything else in the region.
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? Perhaps I was confusing. Sorry. I changed my mind as I wrote my response -- in the end, I don't think this would work, because it would assume that expression splices above the top-level splice could depend on declarations below the top-level splice, which might break existing code (and with no workaround). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9813#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler