Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

Template Haskell: splicing types and patterns
In http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html Simon Peyton Jones writes: ``` We claim to allow you to write splices in (a) types and (b) patterns. I'm very dubious about (b). Consider] x = 4 y :: Patt y = [p| ... |] f $y = x Question: where is x bound? It looks as though x can be bound by the spliced-in pattern or by the top-level binding. You can't tell without knowing what $y expands to. We argue in our paper against non-top-level declaration splices because that would lead to ambiguity of exactly this sort. It turns out that it's very inconvenient to implement pattern splices in GHC, for exactly this reason. We can't figure out the binding structure till we expand the splice. We can't expand the splice till typechecking time. But the renamer currently fixes the binding structure before type checking. Changing this would be a big upheaval. Conclusion: pattern splices are hard to implement, and dubious from a programming point of view. I propose to drop them, for now at least. Type splices have some similar echoes. Consider y :: Type y = [t| a -> a |] f :: $y What is f polymorphic in? The trouble concerns Haskell's implicit quantification. I guess there are three possibilities: a) $y expands to "a -> a", and that is implicitly universally quantified to "forall a. a->a". b) The implicit quantification happens at the [t| ...|] brackets, so that $y expands to "forall a. a->a" c) $y expands to "a -> a" with no implicit quantification anywhere. I'm pretty sure that we should adopt (b). After all, we want a lexical-scoping rule for TH, so we have to say where 'a' is bound. That would still in principle allow y :: Type y = return (Tvar "a" `Arrow` Tvar "a") Since it's the renamer that does implicit quantification, it'd be quite awkward to make the implicit quantification at the splice site "see" the free variables 'a'. The link with the pattern stuff is this. If you see f :: $y -> b then what are the implicit for-alls? My answer: the implicit for-alls are just for "b", not for any free vars of $y. ``` Since then, the only solution for pattern splices I recall seeing is ``` f ${x,z}y = x ``` which asserts that the splice introduces the set of identifiers `{x,z}`. <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | ---------------- | | Version | 6.6.1 | | Type | Bug | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Template Haskell | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | | | Operating system | Unknown | | Architecture | Unknown | </details> <!-- {"blocked_by":[],"summary":"Template Haskell: splicing types and patterns","status":"New","operating_system":"Unknown","component":"Template Haskell","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html Simon Peyton Jones writes:\r\n{{{\r\nWe claim to allow you to write splices in (a) types and (b) patterns.\r\nI'm very dubious about (b). Consider]\r\n x = 4\r\n \r\n y :: Patt \r\n y = [p| ... |]\r\n\r\n f $y = x\r\n\r\nQuestion: where is x bound? It looks as though x can be bound by the\r\nspliced-in pattern or by the top-level binding. You can't tell without\r\nknowing what $y expands to. We argue in our paper against non-top-level\r\ndeclaration splices because that would lead to ambiguity of exactly this\r\nsort.\r\n\r\nIt turns out that it's very inconvenient to implement pattern splices in\r\nGHC, for exactly this reason. We can't figure out the binding structure\r\ntill we expand the splice. We can't expand the splice till typechecking\r\ntime. But the renamer currently fixes the binding structure before type\r\nchecking. Changing this would be a big upheaval.\r\n\r\nConclusion: pattern splices are hard to implement, and dubious from a\r\nprogramming point of view. I propose to drop them, for now at least.\r\n\r\n\r\nType splices have some similar echoes. Consider\r\n \r\n y :: Type \r\n y = [t| a -> a |]\r\n\r\n f :: $y\r\n\r\nWhat is f polymorphic in? The trouble concerns Haskell's implicit\r\nquantification. I guess there are three possibilities:\r\n\r\na) $y expands to \"a -> a\", and that is implicitly universally quantified\r\nto \"forall a. a->a\".\r\nb) The implicit quantification happens at the [t| ...|] brackets, so\r\nthat $y expands to\r\n \"forall a. a->a\"\r\nc) $y expands to \"a -> a\" with no implicit quantification anywhere.\r\n\r\nI'm pretty sure that we should adopt (b). After all, we want a\r\nlexical-scoping rule for TH, so we have to say where 'a' is bound.\r\n\r\nThat would still in principle allow\r\n \r\n y :: Type\r\n y = return (Tvar \"a\" `Arrow` Tvar \"a\")\r\n\r\nSince it's the renamer that does implicit quantification, it'd be quite\r\nawkward to make the implicit quantification at the splice site \"see\" the\r\nfree variables 'a'.\r\n\r\nThe link with the pattern stuff is this. If you see\r\n f :: $y -> b\r\n\r\nthen what are the implicit for-alls? My answer: the implicit for-alls\r\nare just for \"b\", not for any free vars of $y.\r\n}}}\r\n\r\nSince then, the only solution for pattern splices I recall seeing is\r\n{{{\r\nf ${x,z}y = x\r\n}}}\r\nwhich asserts that the splice introduces the set of identifiers `{x,z}`.","type_of_failure":"OtherFailure","blocking":[]} -->
issue