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

Richard O'Keefe ok at cs.otago.ac.nz
Wed Feb 1 03:13:55 CET 2012


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.

I'm reminded of Pop-2, where f(x) and x.f meant exactly the same thing.
Overloading was a (dynamic) property of f, not a property of dot.

Ada had two reasons for adding dot syntax, and much as I admire Ada,
I'm not sure that I agree with either of them.
One was to be more familiar to programmers from other languages, but
since there remain interesting differences between x.f in Ada and x.f
in other languages, it's not clear to me how much of a kindness that
really is.  The other is that x.f means basically what f(x) would have,
*had f(x) been legal*; the aim was to be able to use methods without
having to important everything from a module.

Now that might have some relevance to Haskell.  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.





More information about the Haskell-Cafe mailing list