Proposal: Scoping rule change

[Sittampalam, Ganesh]

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

 

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>
[mailto:haskell-prime-bounces at haskell.org
<mailto: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
<http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html> 
	
========================================================================
======

	
	_______________________________________________
	Haskell-prime mailing list
	Haskell-prime at haskell.org <mailto:Haskell-prime at haskell.org> 
	http://www.haskell.org/mailman/listinfo/haskell-prime
<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/49174cc0/attachment-0001.htm>