Proposal: Scoping rule change

Sittampalam, Ganesh ganesh.sittampalam at
Wed Jul 25 08:48:40 CEST 2012

The "... foo ..." in my example was intended to show that module M does
look up 'foo'.


From: Manuel M T Chakravarty [mailto:chak at] 
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.




"Sittampalam, Ganesh" <ganesh.sittampalam at>:

	If you're using unqualified and unrestricted imports, there's
still the risk that another module will export something you care about,


	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


	From: haskell-prime-bounces at
<mailto:haskell-prime-bounces at>
[mailto:haskell-prime-bounces at
<mailto:prime-bounces at> ] 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

	like to propose a change to Haskell's scoping rules.


	The change is quite simple.  As it is, top level entities in a

	are in the same scope as all imported entities.  I suggest that

	is changed to that the entities from the module are in an inner

	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

	called foo.  After this change the module M no longer compiles

	(under the current scoping rules) the imported foo clashes with

	foo in M.


	Pros: Module compilation becomes more robust under library

	Fewer imports with hiding are necessary.


	Cons: There's the chance that you happen to define a module

	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



	Implementation status: The Mu compiler has used the scoping rule

	several years now and it works very well in practice.


	  -- Lennart



	Please access the attached hyperlink for an important electronic
communications disclaimer:

	Haskell-prime mailing list
	Haskell-prime at <mailto:Haskell-prime at>


Please access the attached hyperlink for an important electronic communications disclaimer: 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Haskell-prime mailing list