[Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Evan Laforge]

The proposal has this sentence, apparently in reference to using
qualified imports: "This is sufficient, but it is just sufficiently
inconvenient that people don't use it much."  Does this mean qualified
imports?  I use them exclusively, and I'd love it if everyone else
used them too.


Anyway, a few concerns about TDNR as prosposed:

One thing I'd really like that this would provide is shorter record
selection.  "b.color" is a lot nicer than "Button.btn_color b".  Or
would it?  It seems like under a TDNR scheme to be able to write
"b.color" I'd have to either import "color" explicitly or go over to
the unqualified import world.  I don't really want to do the latter,
but I also wouldn't want to maintain explicit import lists.  Also, as
far as I can see this doesn't provide is nice record update syntax.
If I can write "b.color" I want to be able to write "b2 = b.color :=
red"!

I think this will also lead to either lots of name shadowing warnings
or more trouble picking variable names.  The short perspicuous names
this allows are also the most convenient for local variables.  I don't
want to suddenly not be able to use a 'color' variable name because
some record has a 'color' field.  A record system (and OO languages)
would have no trouble with 'let color = b.color' but as far as I can
see TDNR would have a problem.

So as far as records, TDNR doesn't seem too satisfactory.

I'm also worried about the use of dot with regards to a possible
future record system.  If we're already using dot for TDNR it's seems
like it would be even harder for a record system to use it.  I'm not
saying this very well, but it seems like both proposals solve
overlapping problems:  TDNR provides convenient "method" calls and
convenient field access as a side-effect, a record system would
provide convenient field access and some form of subtyping.  I think
records are more interesting and I worry that TDNR would lessen
motivation to implement records or make them more tricky to implement.