[Haskell-cafe] generalize RecordPuns and RecordWildCards to work with qualified names?

Simon Peyton-Jones simonpj at microsoft.com
Thu Aug 20 10:29:23 EDT 2009


Evan, Lennart

Thanks for the provocation.  I've committed a patch that fixes all these issues.  Try now!

Simon

Thu Aug 20 13:34:43 BST 2009  simonpj at microsoft.com
  * Improvements to record puns, wildcards
  
  * Make C { A.a } work with punning, expanding to C { A.a = a }
  
  * Make it so that, with -fwarn-unused-matches, 
          f (C {..}) = x
    does not complain about the bindings introduced by the "..".
  
  * Make -XRecordWildCards implies -XDisambiguateRecordFields.
  
  * Overall refactoring of RnPat, which had become very crufty. 
    In particular, there is now a monad, CpsRn, private to RnPat,
    which deals with the cps-style plumbing.  This is why so many
    lines of RnPat have changed.
  
  * Refactor the treatment of renaming of record fields into two passes
  	- rnHsRecFields1, used both for patterns and expressions,
  	     which expands puns, wild-cards
    	- a local renamer in RnPat for fields in patterns
  	- a local renamer in RnExpr for fields in construction and update
    This make it all MUCH easier to understand
   
  * Improve documentation of record puns, wildcards, and disambiguation

| -----Original Message-----
| From: haskell-cafe-bounces at haskell.org [mailto:haskell-cafe-bounces at haskell.org] On
| Behalf Of Evan Laforge
| Sent: 12 August 2009 23:59
| To: Simon Peyton-Jones
| Cc: Augustsson, Lennart; haskell; GHC users
| Subject: Re: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with
| qualified names?
| 
| > | Even is suggesting that instead of reporting an error, in the second
| > | case we could use the translation:
| > |
| > |   f (A.A { A.a }) = a   -->   f (A.A { A.a = a })
| > |
| > | (i.e., when punning occurs with a qualified name, use just the
| > | unqualified part of the name in the pattern)
| >
| > Yes, that'd be possible.   But it seems debatable -- it doesn't *look* as if the
| pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in record
| construction and update.  To be concrete, would you expect these to work too?
| >
| >  g a = A.A { A.a }     -->    g a = A.A { A.a = a }
| >  h x a = x { A.a }     -->    h x a = a { A.a = a }
| 
| Oh, I didn't realize that record punning included construction as
| well.  Yeah, that's a little funky looking.  I don't mind seeing the
| binding form and I think a new reader could figure it out without too
| much trouble but I would be a little confused by the construction form
| and think a new reader would also be confused.
| 
| > With -XDisambiguateRecordFields you could say
| >
| >  g a = A.A { a }
| >
| > which seems better.  (But there's no help for record update, since we don't know
| which data constructor is involved.)
| 
| I didn't know about DisambiguateRecordFields!  Looks like that also
| makes the wildcard work like I want it to.
| 
| The ghc docs for DisambiguateRecordFields don't make this very clear
| to me... it talks about disambiguating names in scope, but if I say
| "R.R { a = val}" I wouldn't expect it to "disambiguate" 'a', which is
| not in scope at all, to 'R.a' which looks like a completely different
| name.  Rereading the paragraph at 7.3.11 I'm still surprised this
| works.  Maybe add something like:
| 
| ... preceeding docs ...
| 
| This also means that if you use qualified imports you can still use
| unqualified field names.  E.g. in the pattern @(R.R { a = a_val })@,
| @a@ will be disambiguated to @R.a@, even if @R@ is imported qualified.
| 
| I gather we're not supposed to call them "records" anymore, they're
| supposed to be something I forget now, but the rest of the ghc docs
| says records, so...
| 
| > So my current conclusion is: improve the error message, perhaps suggesting the
| flag -XDismabiguateRecordFields, but don't add the change you suggest.
| >
| > Comments?
| 
| Sounds good to me.  I'll try adding DisambiguateRecordFields and try
| out the new punning, thanks!
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Glasgow-haskell-users mailing list