On Wed, Nov 18, 2009 at 3:53 PM, Evan Laforge <span dir="ltr"><<a href="mailto:qdunkan@gmail.com">qdunkan@gmail.com</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
The proposal has this sentence, apparently in reference to using<br>
qualified imports: "This is sufficient, but it is just sufficiently<br>
inconvenient that people don't use it much." Does this mean qualified<br>
imports? I use them exclusively, and I'd love it if everyone else<br>
used them too.<br></blockquote>
<br>A possibly irrelevant aside:<br><br>Qualified imports are some times problematic when you need to work with classes from the module. You can't define a member of two instances from different two modules that define classes with conflicting member names. This can lead to situations where you have no option but to have orphan instances. <br>
<br>module Bar where<br>class Foo a where<br> foo :: a<br><br>module Baz where<br>class Quux a where<br> foo :: a<br><br>module Quaffle where<br>import qualified Bar<br>import qualified Baz<br><br>instance Bar.Foo Int where<br>
Bar.foo = 1<br>-- ^- syntax error.<br><br>instance Baz.Quux Int where<br> Baz.foo = 2<br><br>I suppose this could possibly be fixed if something deep in the parser allowed a QName there. <br><br>-Edward Kmett<br><div class="gmail_quote">
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Anyway, a few concerns about TDNR as prosposed:<br>
<br>
One thing I'd really like that this would provide is shorter record<br>
selection. "b.color" is a lot nicer than "Button.btn_color b". Or<br>
would it? It seems like under a TDNR scheme to be able to write<br>
"b.color" I'd have to either import "color" explicitly or go over to<br>
the unqualified import world. I don't really want to do the latter,<br>
but I also wouldn't want to maintain explicit import lists. Also, as<br>
far as I can see this doesn't provide is nice record update syntax.<br>
If I can write "b.color" I want to be able to write "b2 = b.color :=<br>
red"!<br>
<br>
I think this will also lead to either lots of name shadowing warnings<br>
or more trouble picking variable names. The short perspicuous names<br>
this allows are also the most convenient for local variables. I don't<br>
want to suddenly not be able to use a 'color' variable name because<br>
some record has a 'color' field. A record system (and OO languages)<br>
would have no trouble with 'let color = b.color' but as far as I can<br>
see TDNR would have a problem.<br>
<br>
So as far as records, TDNR doesn't seem too satisfactory.<br>
<br>
I'm also worried about the use of dot with regards to a possible<br>
future record system. If we're already using dot for TDNR it's seems<br>
like it would be even harder for a record system to use it. I'm not<br>
saying this very well, but it seems like both proposals solve<br>
overlapping problems: TDNR provides convenient "method" calls and<br>
convenient field access as a side-effect, a record system would<br>
provide convenient field access and some form of subtyping. I think<br>
records are more interesting and I worry that TDNR would lessen<br>
motivation to implement records or make them more tricky to implement.<br>
<div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote><br></div><br>