Proposal: Scoping rule change

Edward Kmett ekmett at gmail.com
Tue Jul 24 14:47:04 CEST 2012


+1 from me

I can't count the number of times I've had this bite me when writing ByteString-like APIs that pun names from the Prelude.

On Jul 23, 2012, at 8:28 PM, Lennart Augustsson <lennart at augustsson.net> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime



More information about the Haskell-prime mailing list