[GHC] #10599: Template Haskell doesn't allow `newName "type"`
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using `type` as a name is, of course, forbidden. OTOH, `type_1` is allowed as a name. However, using GHC 7.10.1 and `ghc --make T.hs` on files: {{{#!hs -- T.hs {-# LANGUAGE TemplateHaskell #-} module T where import Q test -- Q.hs module Q where import Language.Haskell.TH test :: Q [Dec] test = do t <- newName "type" return [FunD t [Clause [] (NormalB $ LitE $ CharL 't') []]] }}} Leads to the following error: {{{ $ ghc --make -ddump-splices T.hs [2 of 2] Compiling T ( T.hs, T.o ) T.hs:6:1: Illegal variable name: ‘type’ When splicing a TH declaration: ident_0 type_1 = type_1 }}} The above example works fine for GHC 7.8.4, so it's a regression. Reference: https://github.com/yesodweb/persistent/issues/412 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by GregWeber): I just tested on 7.10.2 (the docker image which uses the hvr ppa). ``` ➜ th-bug docker run --rm -v `pwd`:/proj -w /proj haskell:7.10.2 ghc T.hs [1 of 2] Compiling Q ( Q.hs, Q.o ) [2 of 2] Compiling T ( T.hs, T.o ) T.hs:5:1: Illegal variable name: ‘type’ When splicing a TH declaration: ident_0 type_1 = type_1 ``` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by GregWeber): * priority: normal => high * version: 7.10.1 => 7.10.2-rc2 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * milestone: => 7.12.1 Comment: Interesting. Part of the confusion here is that names generated by `newName` are different from other names you can use in Haskell. So when you say `newName "type"`, the variable's name really is `type`, but because it comes from `newName`, GHC prints it specially, as it's '''different''' from any other variable named `type`. So what you're trying to do -- create a variable named `type` -- is objectionable. It's just that the pretty-printer makes it look more sensible. On the other hand, there is no reason at all for TH to be picky about `newName` names. GHC got pickier about TH names between 7.8 and 7.10 because 7.8 allowed non-`newName` names that aren't allowed in Haskell, making variables that can't be referred to outside of TH. However, with `newName`, the whole point is that you can't refer to them outside of TH. So I think an improvement would be just to let `newName` be very liberal in what it accepts. As I'm inclined to say that GHC is doing the Right Thing here (that is, rejecting a variable named `type`), it seems most sensible to wait until 7.12 to fix. But if this is ruining your day, speak up. I don't feel very strongly on this point, at all. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): As a brief addendum: You _could_ reference a non-`newName`'d variable named `type` that was produced from within `template-haskell` from within the language before: `Foo.type` parsed just fine as a qualified name. (This has apparently happened in some code folks have out there using `lens`.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me that we should be closing up the cases where `type` can be used as a name, not opening more of these holes. It would be quite confusing to the user if they end up with a situation where a they see an export named `type`, find that it can be imported without trouble if qualified, and then try to define another similarly named definition without of TH, only to find that they get a syntax error. I'm not entirely sure what we want to do about the parsing issue, but it seems that TH's current behavior is what we would want here, no? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by GregWeber):
So when you say newName "type", the variable's name really is type, but because it comes from newName, GHC prints it specially, as it's different from any other variable named type. So what you're trying to do -- create a variable named type -- is objectionable
This isn't the goal here. If it was, `mkName` would be used.
It seems to me that we should be closing up the cases where type can be used as a name, not opening more of these holes. It would be quite confusing to the user if they end up with a situation where a they see an export named type, find that it can be imported without trouble if qualified, and then try to define another similarly named definition without of TH, only to find that they get a syntax error.
Again, "type" is not being used for a name but instead to seed a new name From a TH user perspective it seems that in 7.10 `newName` has become a leaky abstraction where I am forced to understand how GHC is internalizing these names in a way that is different than what is printed out. As a library author, I can certainly work around this. But it isn't something I would think to test and I only found out about it when a user reported that their program stopped working on 7.10. So at this point there is no way for us to quantify the breakage it would cause. I would expect it to be fairly rare that a name gets into a TH function that is reserved as an identifier: for persistent this happens because it later adds a record field prefix to the name before generating a record field. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 bgamari]:
It would be quite confusing to the user if they end up with a situation where a they see an export named `type`,
Ah. Good point. I hadn't thought about exports. If `newName`s were used only as locals, we would be fine with a very liberal treatment for `newName`. But once we think about exporting, we do run into an issue. Come to think of it, we really shouldn't allow exporting of names created with `newName`. As Greg has pointed out, there's no reason a user should assume that a `newName "foo"` creates a variable named `foo`. If we allow exporting, then `newName`s are leaky, indeed. If we disallow exports, would that alleviate your concerns, Ben? At that point, we should really allow any (non-empty?) string as the argument for `newName`. I think Greg is spot on in suggesting that the argument to `newName` is merely a seed, not the name in question. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): I likewise agree with Greg. I'd expect to be able to call `newName` with more or less anything. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
If we disallow exports, would that alleviate your concerns, Ben? At that
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:7 goldfire]: point, we should really allow any (non-empty?) string as the argument for `newName`. I think Greg is spot on in suggesting that the argument to `newName` is merely a seed, not the name in question. This sounds fine to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jb55): * cc: jb55 (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by k-bx): Just to mention that it affected our codebase, because we use {{{ $(makeLensesWith abbreviatedFields ''Geo) }}} And some fields happen to be named like "_fooType". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My first step toward fixing this is prohibiting export of `newName` names. But it strikes me that a good approach is to avoid adding system names to the `GlobalRdrEnv`. `newName` names are indeed system names, and I think, in general, users should never be able to refer to system names in code. Is there a reason this is a bad approach? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds plausible to me. Names you export should be civilised. But how could they be exported anyway? You can't mention it in the export list, presumably. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 simonpj]:
But how could they be exported anyway? You can't mention it in the export list, presumably.
But you can. :( {{{ {-# LANGUAGE TemplateHaskell #-} module TestTH ( bar ) where import Language.Haskell.TH $( do bar <- newName "bar" return [ValD (VarP bar) (NormalB (ConE 'True)) []] ) }}} They also get exported with an omitted export list. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AlexanderThiemann): Just a side note: the same thing happens when you use `instance` instead of `type`. This is probably broken for all "reserved" identifiers? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that's right. I hope to fix this for 8.0, but time is short right now! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It seems pretty unlikely that this will happen for 8.0.1, although who knows what might happen. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2 either. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.4.1 => 8.6.1 Comment: Nor will it happen for 8.4. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by k-bx): * cc: k-bx (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC