Proposal: Scoping rule change

[Sittampalam, Ganesh]

My point is that if you would rather not get that error when J changes,
you need to use explicit import lists:

 

Module M

import I (foo)

import J ()

 

definitioninModuleM = foo

 

Lennart's proposed change makes explicit import lists unnecessary for
the case where foo is defined inside M rather than being imported from I
- but as it doesn't avoid the need for them in general I'm not sure that
it is worth it.

 

Ganesh 

 

 

From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au] 
Sent: 25 July 2012 10:25
To: Sittampalam, Ganesh
Cc: Lennart Augustsson; Haskell Prime
Subject: Re: Proposal: Scoping rule change

 

"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
<http://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
<mailto: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
<http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html> 
	
========================================================================
======

 


=============================================================================== 
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/8f126adb/attachment-0001.htm>