[GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Language.Haskell.TH.Syntax` it reads on the generation of fresh names: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, this:
g = $(do nm1 <- newName "x" let nm2 = mkName "x" return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) )
will produce the splice
g = \x -> \x0 -> x0
since the occurrence @VarE nm2@ is captured by the innermost binding of @x@, namely @VarP nm1@. }}} I find this note quite misleading, especially since the above splice normally generates something like {{{ \ x -> \ x_a3vv -> x }}} where no inadvertent capture occurs. I belive this note should rather be something as follows: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, suppose that the next invocation of newName would generate the name nm1 = x0, and we have the following splice, where mkName uses the very same name x0 for nm2:
g = $(do nm1 <- newName "x" let nm2 = mkName "x0" return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) )
This will produce the following splice, where nm1 generated by newName captures nm2 assigned by mkName:
g = \x0 -> \x0 -> x0
In particular, now the occurrence @VarE nm2@ is captured by @VarP nm1@ and not by @VarP nm2" anymore (as was intended by the TH AST). }}} I'm happy to change this, if people agree :-). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That comment seems utterly wrong to me. Can you observe the weird capturing behavior described? What's your example? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): Yea, I thought the comment to be wrong at first glance as well, in particular since I couldn't observe this capturing behavior at all: The mentioned splice generates something like {{{ \ x -> \ x_a3vv -> x }}} Which is exactly as specified in the TH AST and thus as expected. But at 2nd reading I was thinking that the original intent of this comment might have been to explain that a newly generated Name via `newName` might clash with the name chosen by `mkName`. That is, suppose `newName` would generate the name `x_1234` next, and by bad luck we generate the same name `x_1234` by means of `mkName`. Then these two names might interfere and capturing results (see my revised message in the ticket description at the very end for more details). Or is this case not possible and we should just remove this comment entirely instead of modifying it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Without going into that code deeply, I think this comment is just wrong. My best advice is to try to reproduce the behavior it suggests. If that fails, delete the comment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't understand what you are all talking about :) Try this complete program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH g = $(do nm1 <- newName "x" let nm2 = mkName "x" return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) ) main = putStrLn $ g "1" "2" }}} It outputs `2`, as advertised by the comment in question. I happened to be looking at this the other day for unrelated reasons. `mkName "x"` means "whatever variable of name `x` is in scope", and `newName "x"` returns a new variable whose name is `x`. It is a different variable than is returned by other calls to `newName "x"`, but all of them capture the name `x` as far as `mkName` is concerned. As far as I can tell it's all exactly as explained in that comment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That's surprising to me, but not so terribly surprising. That's why I wanted a test before deleting the comment! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): @rwbarton: interesting. Thanks for clarifying the true nature of this comment! I sadly hadn't run the generated splice `g "1" "2"` as you then suggested, but had found the comment misleading solely based on enabling the `-ddump- splices` flag. When enabled, the splice in your program expands to something like: {{{ \ x -> \ x_a3uK -> x }}} And thus I thought, that the comment of `newName` capturing `mkName`s didn't make sense at all, since the generated splice agrees with the specified TH AST. Hence, it seems that the splice expansion displayed by `-ddump-splices` does not agree with what is actually generated when running the code `g "1" "2"`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah, yes, that makes some sense. When the pretty-printer appends `_xyz` to an identifier, that's the identifier's `Unique`. TH `Name`s sometimes lead to identifiers with `Unique`s (e.g., `newName` identifiers and identifiers from quoting) and sometimes not (`mkName`). In the latter case, the variable will refer to the innermost identifier with the same name, regardless of its `Unique`. I agree the pretty-printer is confusing here. Maybe instead of `x_a3uK`, it should be `x{a3uK}`? It would then be clear that the underscore isn't part of the name proper. Not sure if this is better or worse. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11584#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC