-XDuplicateRecordFields breaks record expression splices

{-# language TemplateHaskell #-}
{-# language DuplicateRecordFields #-}
module Lib where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax

data A = A {x :: Int, y :: String}
a = A 3 "test"
test = $([e|case a of A {x = b} -> b|])

Without DuplicateRecordFields it compiles correctly so test = 3 but with DuplicateRecordFields enabled it gives:

     • Illegal variable name: ‘$sel:x:A’
      When splicing a TH expression:
        case Lib.a of
    (Lib.A {Lib.$sel:x:A = b_0}) -> b_0
    • In the untyped splice: $([| case a of { A {x = b} -> b } |])

Additionally, there doesn't seem to be a workaround for munging the name manually, since the $sel:x:A name is the one actually in scope, there is no A.x like there would be normally, even when the label is not a duplicate.

Is there a way to get around this? Ex: by changing the binding name somehow manually?

Trac metadata

Trac field	Value
Version	8.2.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

added OverloadedRecordFields label

I think a possible fix here is to apply the approach described in Note [Reifying field labels] from TcSplice in the HsRecFld case of DsMeta.repE. That is, rather than representing the field as a NameG containing the mangled selector name (which isn't a legal variable name, let alone in scope), we could represent it as a NameQ containing the field label.

I've just rediscovered this issue, and the interaction between DuplicateRecordFields and TemplateHaskell definitely needs to be addressed more carefully.

The problem here is the case for HsRecFld in DsMeta.repE, which simply replaces the field occurrence with the selector function (which has an internal name that cannot be spliced in, namely Name "$sel:x:A" (NameG VarName pkg "Lib")). There are other related problems in DsMeta for representing fields in record definition, construction and pattern matching.

The way #11103 (closed) dealt with a similar problem in reification was to represent field names using a specially-crafted NameQ, rather than a NameG. In this example that approach would give Name "x" (NameQ "Lib") instead. Note that NameG cannot be used with the field label in place of the selector, because that leads to looking up an Orig name that doesn't exist.

However, while using NameQ should fix this example, it doesn't work in general: it means the name is dynamically bound, but of course the field might not be in scope when the splice is run. For a concrete example of this, consider a tiny variant of the test case from #12993 (closed):

{-# LANGUAGE DuplicateRecordFields #-}
{-# LANGUAGE TemplateHaskell #-}
module T12993_Lib (q) where
data X = X { x :: Int }
q = [|x|]

{-# LANGUAGE TemplateHaskell #-}
module T12993 where
import T12993_Lib
f = $(q)

This currently fails with an "Illegal variable name" error similar to the original report from this ticket. With the NameQ approach, it would still fail because x is not in scope in T12993.

It seems fairly clear to me that dealing with this properly requires extending the TH AST in some way. The least invasive option might be to extend NameFlavour with a new constructor for field names, which would be rather like NameG but would carry the selector name. I'm not sure if there are better designs, however. What is the process for proposing/discussing such changes to TH?

Trac metadata

Trac field	Value
Related	- → #11103 (closed)

assigned to @adamgundry

The least invasive option might be to extend NameFlavour with a new constructor for field names, which would be rather like NameG but would carry the selector name.

I've tried this, and it looks like a relatively straightforward change (although we may need an equivalent to NameL as well, I'm not sure yet). Will propose a patch.

Was there any progress on this patch? Being able to disambiguate between different selectors for overloaded fields would be very useful.

I'm sorry, I dropped the ball on this one, so it is currently stalled. There are a family of TH/DuplicateRecordFields interaction tickets that really need sustained attention, which I've been unfortunately unable to find so far.

added Pnormal label

mentioned in issue #17381 (closed)

mentioned in issue #17551 (closed)

added TemplateHaskell label

mentioned in merge request !3330 (closed)

mentioned in issue #18598 (closed)

marked this issue as related to #19664 (closed)

marked #20098 (closed) as a duplicate of this issue

marked this issue as related to #20098 (closed)

mentioned in issue #20098 (closed)

marked this issue as related to #21720 (closed)

marked #22809 (closed) as a duplicate of this issue

marked this issue as related to #22809 (closed)

mentioned in issue #22809 (closed)

assigned to @sheaf and unassigned @adamgundry

I will be fixing in !8686 (merged).

closed with merge request !8686 (merged)

mentioned in commit 3f374399