On 1/02/2012, at 7:10 PM, Anthony Clayden wrote:
On 1/02/2012, at 11:38 AM, AntC wrote:
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.
Richard O'Keefe wrote: ... Making f x and x.f the same is pretty appealing, but it is imaginable that the former might require importing the name of f from a module and the latter might not. That is to say, it lets f and .f have completely different meanings. Oh the joy! Oh the improved readability! -- on some other planet, maybe.
Hi Richard, I'm not sure I understand what you're saying.
I'm saying that if dot is to do anything at all that it does not do now, then f x and x.f being identical is sort of OK ( though it does rather clash with f . g), but any differences between them would be confusing.
This is all so weird I'm inclined to say that one-sided dot is probably a syntax error, and reject it.
It wasn't a syntax error, it just wasn't intended to be Haskell code at all, just an ad hoc English text abbreviation for "f occurring after a dot". Of course (x.) = \f -> f x and (.f) = \x -> f x are precisely the kind of sections people will expect to be legitimate once they've seen (x.f)... Of course, if f x and x.f mean the same thing, we don't need x.f, do we?