Proposal: Scoping rule change

[Sittampalam, Ganesh]

Hi Iavor,

In your example using "import qualified" would also resolve the clash,
although if you were importing two symbols from Text.PrettyPrint you
might like to be able to use the other one unqualified.

In my experience using the current module name for qualification is
pretty rare already, but perhaps it's just a question of different
styles.

Cheers,

Ganesh

-----Original Message-----
From: haskell-prime-bounces at haskell.org
[mailto:haskell-prime-bounces at haskell.org] On Behalf Of Iavor Diatchki
Sent: 25 July 2012 18:46
To: Lennart Augustsson
Cc: Haskell Prime
Subject: 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 useful, even if
one is willing to list all names in all imports explicitly, because it
makes it possible to leave off qualifiers on names defined in the
current module, which reduces clutter.  Here is an example that I run
into quite often:

    module Data.MyList (empty) where
    import Text.PrettyPrint as P (empty)

    empty = []

    singleton x = x : Data.MyList.empty
    -- vs.
    singleton x = x : empty  -- using new scoping rule

    ppList = ... P.empty ...  -- We only need to qualify imported things

Note that with the new scoping rule we wouldn't need to ever use the
current module as a qualifier, which is kind of nice, especially since
we have no way to give it a shorter name (like we can for imports).

-Iavor


On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson
<lennart at augustsson.net> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>

_______________________________________________
Haskell-prime mailing list
Haskell-prime at 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 
===============================================================================