Narrow the use of record wildcards slightly
authorSimon Peyton Jones <simonpj@microsoft.com>
Thu, 23 Jun 2016 08:02:00 +0000 (09:02 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Thu, 23 Jun 2016 08:24:49 +0000 (09:24 +0100)
commit2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd
tree11b00870efc80e50d5a0dc1c07aa89c42689ca1f
parent643706e44935cd15c2248e5345dadd3e9804688e
Narrow the use of record wildcards slightly

In reviewing the fix to Trac #12130 I found the wild-card
fill-in code for ".." notation in record constructions hard
to understand.  It went to great contortions (including the
find_tycon code) to allow
    data T = C { x, y :: Int }
    f x = C { .. }
to expand to
    f x = C { x = x, y = y }
where 'y' is an /imported function/!  That seems way over the top
for what record wildcards are supposed to do.

So I have narrowed the record-wildcard expansion to include only
/locally-bound/ variables; i.e. not top level, and certainly not
imported.

I don't think anyone is using record wildcards in this bizarre way, so
I don't expect any fallout. Even if there is, you can easily
initialise fields with eponymous but imported values by hand.

An intermediate position would be to allow /local/ top-level
definitions.  But I doubt anyone is doing that either.

Let's see if there's any fallout.  It's a local change, easy to
revert, so I've just gone ahead to save everyone's time.
compiler/rename/RnPat.hs
docs/users_guide/glasgow_exts.rst