RE: Proposal: Scoping rule change

[Sittampalam, Ganesh]

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-boun...@haskell.org
[mailto:haskell-prime-boun...@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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Proposal: Scoping rule change

[Edward Kmett]

+1 from me

I can't count the number of times I've had this bite me when writing 
ByteString-like APIs that pun names from the Prelude.

On Jul 23, 2012, at 8:28 PM, Lennart Augustsson  wrote:

> 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
> 
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Proposal: Scoping rule change

[Manuel M T Chakravarty]

Nitpick: Your example actually does not lead to an error with GHC, as you 
define, but do not use 'foo' in M. Names (like classes) only clash when you 
look them up.

Manuel

Lennart Augustsson :
> 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
> 
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Proposal: Scoping rule change

[Manuel M T Chakravarty]

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" :
> 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-boun...@haskell.org 
> [mailto:haskell-prime-boun...@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@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: 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:c...@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" :

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-boun...@haskell.org

[mailto:haskell-prime-boun...@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@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 
=== 

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime