Donn Cave
Quoth AntC
, ... My proposal is that field selection functions be just ordinary functions,
dot notation be just function application(tight-binding). Then: object.fieldfuncmethod ==> fieldfuncmethod object (Subject to the tight binding for the dot.) And one-sided dot application is pointless (! errk I mean 'without
and purpose',
no different to writing the bare object or bare fieldfuncmethod).
That's interesting! The wiki page on SORF (Simple Overloaded Record Fields, http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields) has some language that, as I interpreted it, meant that Has/Get syntactic sugar depended on the dot, so it's indispensable.
Yes it does, and that's one of the things I didn't like - hence my counter- proposal. In particular in SORF, the dot notation got tied into 'virtual record selectors'. Now 'virtual record selectors' is a good idea, but SORF tied it to the field selection approach, so had to go via a Has instance, which introduced a `set' method as well as the get, which didn't make sense, so SPJ ran into trouble. Actually the TDNR proposal was better re the "power of the dot": "works with any function". As soon as you decide to make 'virtual record selectors' just ordinary functions (so they select but not update), then you can see that field names are also just ordinary functions (for selection purposes). So the semantics for field 'selection' (whether or not you use dot notation) is just function application. So Type-Directed Name resolution is just instance resolution. So it all gets much easier.
Your proposal actually has some similar language but, I see you don't mean it that way. That's great news for anyone who's really dying to get somewhere with records, if it means that the functionality could in principle be introduced independently of ...
Yes. Actually, (IMHO) the biggest block to making some progress with the 'cottage industry' for records (and there are heaps of ideas out there) is that currently the field name appearing in data decls grabs so much of the namespace real estate. It creates a global name (selector function) that can't be overloaded. You'll see in my other posts last night (NZ time) that the first thing I think should happen is to switch off auto-creation of field selection functions. (This should have come along as an option with DisambiguateRecordFields, I think. http://www.haskell.org/pipermail/glasgow-haskell-users/2012- January/021750.html)
... changes to the interpretation of "." that would break a lot of code.
Yes, in principle we could introduce the semantics for field-selectors-as- overloaded-functions without introducing any special syntax for field selection (dot notation or whatever). But the 'Records in Haskell' thread started with a Reddit/Yesod discussion about records, and the lack of dot notation being the last major wart in Haskell. "A sentiment open to doubt" in the words of the poet. It stung SPJ enough to open up the discussion (and I guess now is timely as 7.4.1 gets put to bed). For me, the record/field namespacing is the major wart, polymorphism only slightly less, and the notation is a side-issue. But I don't want to lose the initiative that's built up, so I'm trying to address both at the same time. AntC