Proposal: Scoping rule change

Manuel M T Chakravarty chak at cse.unsw.edu.au
Wed Jul 25 08:26:06 CEST 2012


If Lennart's suggestion is combined with GHC's lazy checking for name clashes (i.e., only check if you ever look a name up in a particular scope), it would also work in your example.

Manuel

"Sittampalam, Ganesh" <ganesh.sittampalam at credit-suisse.com>:
> If you’re using unqualified and unrestricted imports, there’s still the risk that another module will export something you care about, e.g.
>  
> module M where
> import I  -- currently exports foo
> import J  -- might be changed in future to export foo
>  
> … foo …
>  
> So I think you need to use import lists or qualified anyway to avoid any risk of future name clashes – given that, does this change buy much?
>  
> From: haskell-prime-bounces at haskell.org [mailto:haskell-prime-bounces at haskell.org] On Behalf Of Lennart Augustsson
> Sent: 24 July 2012 02:29
> To: Haskell Prime
> Subject: 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
>  
> 
> ==============================================================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20120725/69109f3d/attachment.htm>


More information about the Haskell-prime mailing list