On Wed, Nov 18, 2009 at 3:53 PM, Evan Laforge <qdun...@gmail.com> wrote:
> 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. > A possibly irrelevant aside: 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. module Bar where class Foo a where foo :: a module Baz where class Quux a where foo :: a module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where Bar.foo = 1 -- ^- syntax error. instance Baz.Quux Int where Baz.foo = 2 I suppose this could possibly be fixed if something deep in the parser allowed a QName there. -Edward Kmett > 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. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe