[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[Richard O'Keefe]

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?