[Haskell-cafe] Some thoughts on Type-Directed Name Resolution
ok at cs.otago.ac.nz
Thu Feb 2 05:29:21 CET 2012
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,
> 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?
More information about the Haskell-Cafe