Re: Proposal: Scoping rule change
An optional shadowing warning (for the paranoid) seems reasonable. On Tue, Jul 24, 2012 at 1:45 AM, Greg Weber wrote: > sounds good. will there be a shadowing warning? > > On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson > wrote: > > 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
Re: Proposal: Scoping rule change
sounds good. will there be a shadowing warning? On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson wrote: > 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
Proposal: Scoping rule change
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
