Nitpick: Your example actually does not lead to an error with GHC, as you define, but do not use 'foo' in M. Names (like classes) only clash when you look them up.
Manuel Lennart Augustsson <lenn...@augustsson.net>: > It's not often that one gets the chance to change something as > fundamental as the scoping rules of a language. Nevertheless, I would > like to propose a change to Haskell's scoping rules. > > The change is quite simple. As it is, top level entities in a module > are in the same scope as all imported entities. I suggest that this > is changed to that the entities from the module are in an inner scope > and do not clash with imported identifiers. > > Why? Consider the following snippet > > module M where > import I > foo = True > > Assume this compiles. Now change the module I so it exports something > called foo. After this change the module M no longer compiles since > (under the current scoping rules) the imported foo clashes with the > foo in M. > > Pros: Module compilation becomes more robust under library changes. > Fewer imports with hiding are necessary. > > Cons: There's the chance that you happen to define a module identifier > with the same name as something imported. This will typically lead to > a type error, but there is a remote chance it could have the same > type. > > Implementation status: The Mu compiler has used the scoping rule for > several years now and it works very well in practice. > > -- Lennart > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
