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? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
