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

AntC anthony_clayden at clear.net.nz
Tue Jan 31 23:38:24 CET 2012

Donn Cave <donn <at> avvanta.com> writes:

> Quoth AntC <anthony_clayden <at> clear.net.nz>,
> ...
> > My proposal is that field selection functions be just ordinary functions, 
> > dot notation be just function application(tight-binding). Then:
> >       object.fieldfuncmethod   ==> fieldfuncmethod object
> > (Subject to the tight binding for the dot.)
> > And one-sided dot application is pointless (! errk I mean 'without 
> > no different to writing the bare object or bare fieldfuncmethod).
> That's interesting!  The wiki page on SORF (Simple Overloaded Record Fields,
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields)
> has some language that, as I interpreted it, meant that Has/Get syntactic
> sugar depended on the dot, so it's indispensable. 

Yes it does, and that's one of the things I didn't like - hence my counter-
proposal. In particular in SORF, the dot notation got tied into 'virtual 
record selectors'. Now 'virtual record selectors' is a good idea, but SORF 
tied it to the field selection approach, so had to go via a Has instance, 
which introduced a `set' method as well as the get, which didn't make sense, 
so SPJ ran into trouble.

Actually the TDNR proposal was better re the "power of the dot": "works with 
any function".

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.

>  Your proposal actually
> has some similar language but, I see you don't mean it that way.  That's
> great news for anyone who's really dying to get somewhere with records,
> if it means that the functionality could in principle be introduced
> independently of ...

Yes. Actually, (IMHO) the biggest block to making some progress with 
the 'cottage industry' for records (and there are heaps of ideas out there) is 
that currently the field name appearing in data decls grabs so much of the 
namespace real estate. It creates a global name (selector function) that can't 
be overloaded.

You'll see in my other posts last night (NZ time) that the first thing I think 
should happen is to switch off auto-creation of field selection functions. 
(This should have come along as an option with DisambiguateRecordFields, I 
think. http://www.haskell.org/pipermail/glasgow-haskell-users/2012-

> ... changes to the interpretation of "." that would break
> a lot of code.

Yes, in principle we could introduce the semantics for field-selectors-as-
overloaded-functions without introducing any special syntax for field 
selection (dot notation or whatever). But the 'Records in Haskell' thread 
started with a Reddit/Yesod discussion about records, and the lack of dot 
notation being the last major wart in Haskell. "A sentiment open to doubt" in 
the words of the poet. It stung SPJ enough to open up the discussion (and I 
guess now is timely as 7.4.1 gets put to bed).

For me, the record/field namespacing is the major wart, polymorphism only 
slightly less, and the notation is a side-issue. But I don't want to lose the 
initiative that's built up, so I'm trying to address both at the same time.


More information about the Haskell-Cafe mailing list