Proposal: Scoping rule change

[Manuel M T Chakravarty]

"Sittampalam, Ganesh" <ganesh.sittampalam at credit-suisse.com>:
> The “… foo …” in my example was intended to show that module M does look up ‘foo’.

I did read that as foo is both defined and used in the body. In that case, everything should work just fine.

If you use, but do not define foo, then you definitely want to get an error if J exports foo in the future. So, I think, that is fine.

Manuel

> 
> From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au] 
> Sent: 25 July 2012 08:26
> To: Sittampalam, Ganesh
> Cc: Lennart Augustsson; Haskell Prime
> Subject: Re: Proposal: Scoping rule change
>  
> 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
>  
> 
> ==============================================================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================

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