Overloaded record fields

[AntC]

> Simon Peyton-Jones <simonpj <at> microsoft.com> writes:
> 
> |  record projections.  I would prefer to have dot notation for a
> |  general, very tightly-binding reverse application, ...
> |  Such a general reverse application dot would
> |  allow things like "string.toUpper" and for me personally, it would
> |  make a Haskell OO library that I'm working on more elegant...
> 
> Actually I *hadn't* considered that.   I'm sure it's been suggested 
before (there has been so much
> discussion), but I had not really thought about it in the context of our 
very modest proposal.

Thanks Simon, 

I'd better start by saying that I'm very keen for Adam to get going on 
this and produce something/anything better than H98's record fields. So I 
fully understand you're trying to make this a minimal proposal.

At risk of "I told you so" dot as postfix apply is exactly what I had in 
mind for my record proposals (DORF and TPDORF on the wiki):

- Since H98 field selectors are just functions we could leave them as is
  (leave the selector as Mono/specific to a data type)
- make the new OverloadedRecordFields also just functions
  (via the Has instance
   -- in effect this is PolyRecordFields per the wiki Plan.)
- make Virtual record fields just functions
  (don't need a Has instance, and don't get into trouble with update)
- (then toUpper could seem like a record field kinda thing)

All of them could use the dot notation syntax. (As tight-binding reverse 
function apply.)

    person.lastName.toUpper    -- <==> toUpper (lastName person)

So, as you say:
> 
> It also allows you to use record field names in prefix position, just as 
now, which is a good thing.  
> 
> In fact, your observation allows us to regard our proposal as consisting 
of two entirely orthogonal parts
>   * Generalise the type of record field selectors
>   * Introduce period as reverse function application
> 

Exactly! (I did tell you so: 
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFi
elds/DotPostfix -- billed as "optional syntactic sugar")
So make those two orthogonal extensions. 

For people who really don't like breaking their existing code that uses 
dot as composition in tight-binding contexts (and they were vociferous), 
they simply don't switch on the ‑XDotPostfixFuncApply extension, and they 
can still get the benefits of OverloadedRecordFields.