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

[Anthony Clayden]

> 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 proposing x.f is _exactly_ f x. That is, the x.f gets
desugared at an early phase in compilation.
If the one needs importing some name from a module, than so
does the other.

A 'one-sided dot doesn't mean anything. (Also, I feel
vaguely nauseous even seeing it written down.)
Under my proposal, the only thing .f could mean is:
     \z -> z.f
which desugars to
     \z -> f z
which means (by eta-reduction)
      f

And to complete the story: the only thing (x.) could mean
is:
     \g -> x.g
So a use like:
     (x.) f            -- or z f, where z = (x.)
would desugar to
      f x
which is the same as x.f
A use like (x.)f (no spaces around the parens) would amount
to the same thing.


This is all so weird I'm inclined to say that one-sided dot
is probably a syntax error, and reject it. It's too
dangerously ambiguous between the syntax for 'proper' dot
notation and function composition.

Or is there something I'm not understanding?
[Good to see another NZ'er on the list, by the way.]

AntC