From claus.reinke at talk21.com  Mon Sep 10 19:02:26 2007
From: claus.reinke at talk21.com (Claus Reinke)
Date: Mon Sep 10 20:57:25 2007
Subject: curiosity, bug, or just dead code?
Message-ID: <023301c7f410$1804a480$e6238351@cr3lt>

consider this module, which is accepted by ghci-6.6.1:

    module T where
    import qualified Prelude as T(length)
    import Prelude(length)
    length = 0

there is no way to refer to either length, as both 'length' 
and 'T.length' are ambiguous (ghci complains on uses 
of either name). but is it a bug?

then again, everything is implicitly exported, and there are 
two possible 'T.length'.. (hugs [20051031] complains 
about conflicting exports, on loading T).

now for the good part:

    module Q where
    import T
    main = print T.length

loads fine, and running main returns 0.

    Ok, modules loaded: Q, T.
    *Q> main
    0

so this must be a bug, right? or a matter of interpretation?

not everything is exported implicitly: imported items, whether 
unqualified or qualified and renamed to share the current 
module as qualifier are not exported by default. and changing 

    module T where

to 

    module T(module T) where

leads to conflicting export errors on load in ghci.

currently, i think ghci is right, and hugs is wrong (note that
my hugs is rather old, though), but it wasn't what i expected.

claus


From ross at soi.city.ac.uk  Mon Sep 10 21:30:19 2007
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Mon Sep 10 21:20:31 2007
Subject: curiosity, bug, or just dead code?
In-Reply-To: <023301c7f410$1804a480$e6238351@cr3lt>
References: <023301c7f410$1804a480$e6238351@cr3lt>
Message-ID: <20070911013019.GA6033@soi.city.ac.uk>

On Tue, Sep 11, 2007 at 12:02:26AM +0100, Claus Reinke wrote:
> consider this module, which is accepted by ghci-6.6.1:
>
>    module T where
>    import qualified Prelude as T(length)
>    import Prelude(length)
>    length = 0

All the GHC behaviour described above follows the Haskell 98 Report.
This treatment of omitted export lists is a documented bug in Hugs
(section 5.1.4 of the User's Guide).

On Mon, Sep 10, 2007 at 06:15:20PM -0700, Tim Chevalier wrote:
> This seems like a GHC bug to me. The Haskell 98 report says:
> "It is legal for more than one module in scope to use the same
> qualifier, provided that all names can still be resolved
> unambiguously." (section 5.3.3)

I think "all names" there was intended to mean all references in the
program (cf 5.5.2).  The module exports the locally defined length,
and there is no reference to T.length.
From trac at galois.com  Mon Sep 17 02:50:48 2007
From: trac at galois.com (Hugs)
Date: Mon Sep 17 02:50:34 2007
Subject: [Hugs] #77: Binding variables on the prompt
Message-ID: <061.6b3d732dd2fa7045e98b8b148796600d@localhost>

#77: Binding variables on the prompt
-------------------------------------------------+--------------------------
 Reporter:  apfelmus                             |       Owner:  nobody 
     Type:  enhancement                          |      Status:  new    
 Priority:  major                                |   Milestone:         
Component:  hugs                                 |     Version:  current
 Keywords:  interactive prompt variable binding  |  
-------------------------------------------------+--------------------------
In GHCi, it's possible to bind variables at the interactive prompt, like

 {{{
  > let x = 1
  > x + 1
  2
  > y <- readFile "Foo.bar"
  "Hello World"
  > length y
  11
 }}}

 The rule is that the bindings are legal in the do-notation for the IO-
 monad. For details, see
 [http://www.haskell.org/ghc/docs/latest/html/users_guide/ch03s04.html
 Interactive evaluation at the prompt] in the GHC user's guide. I'm dearly
 missing this feature in Hugs!

-- 
Ticket URL: <http://hackage.haskell.org/trac/hugs/ticket/77>
Hugs <http://www.haskell.org/hugs/>
Hugs 98, an interpreter for Haskell