Proposal: Scoping rule change
ganesh.sittampalam at credit-suisse.com
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 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.
"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,
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 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
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
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
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.
Please access the attached hyperlink for an important electronic
Haskell-prime mailing list
Haskell-prime at haskell.org <mailto:Haskell-prime at haskell.org>
Please access the attached hyperlink for an important electronic communications disclaimer:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-prime