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

Paul R paul.r.ml at gmail.com
Sat Jan 28 14:00:27 CET 2012

AntC> Steve, I think that proposal has been rather superseeded by 
AntC> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields, which 
AntC> draws on TDNR. But SORF is best seen as an evolving design space, with precise 
AntC> details yet to be clarified/agreed. I've put my own variation into the ring: 
AntC> http://www.haskell.org/pipermail/glasgow-haskell-users/2011-
AntC> December/021298.html     -- which seems to have fallen into a black hole :-(

AntC> One of the aspects of TDNR that wasn't so popular was that its type-directed 
AntC> resolution was very similar to instance resolution, but subtly and confusingly 
AntC> different.

AntC> I guess we have to be very careful about the dot. It seems to be in a 
AntC> very 'crowded' syntax space, so if we implement the wrong way, we could end up 
AntC> shutting the door with the keys left inside.

AntC> (...)

All this dot syntax magic frankly frightens me. Haskell, as a pure
functionnal language, requires (and allows !) a programming style that
just does not mix well with object oriented practices. Stretching the
syntax to have the dot feel a-bit-but-not-really like object oriented
programming, mainly to have IDE autocompletion on some cases, does not
make much sens.

If the editor matters - and it probably does -, we could rather take
a more ambitious path, and work on a real semantic editor, as opposed to
a plain left-to-right text editor, with hacked semantic goodies to
alleviate the pain. 

Indeed, very often in haskell, we just don't think code left to right,
or top to bottom. Emacs ability to move point quickly certainly helps,
but I'd surely welcome a drastic switch, to something allowing us to
work directly on type-checked syntax trees.


More information about the Haskell-Cafe mailing list