t: Re: Proposal: Scoping rule change
Hello,
I also think that this is a good idea.
To address Manuel's nitpick, here is an example that would break if
`I` starts exporting `foo`.
module M(foo) where
import I
foo = True
To Ganesh's point: I think that this change would be usefu
Hello,
I also think that this is a good idea.
To address Manuel's nitpick, here is an example that would break if
`I` starts exporting `foo`.
module M(foo) where
import I
foo = True
To Ganesh's point: I think that this change would be useful, even if
one is willing to list all names
Heinrich Apfelmus wrote:
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
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 sa
ime
Subject: Re: Proposal: Scoping rule change
"Sittampalam, Ganesh" :
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
y 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:c...@cse.unsw.edu.au]
> Sent: 25 July 2012 08:26
> To: Sittampalam, Ganesh
> Cc: Lennart Augustsson; Haskell Prime
> Subject: Re: Proposal: Scop
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 cha
alified 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
> Subjec
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
+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
: 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 mod
An optional shadowing warning (for the paranoid) seems reasonable.
On Tue, Jul 24, 2012 at 1:45 AM, Greg Weber wrote:
> sounds good. will there be a shadowing warning?
>
> On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson
> wrote:
> > It's not often that one gets the chance to change somethi
sounds good. will there be a shadowing warning?
On Mon, Jul 23, 2012 at 5: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 rule
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 ent
14 matches
Mail list logo
