Opened 7 years ago

Last modified 7 years ago

#2344 new feature request

oddity with package prefixes for data constructors

Reported by: claus Owned by:
Priority: normal Milestone:
Component: GHCi Version: 6.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:



$ ./ghc-6.9.20080514/bin/
GHCi, version 6.9.20080514:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> :browse Data.Time.Clock
getCurrentTime :: IO UTCTime
newtype DiffTime
  = time- Data.Fixed.Pico
newtype NominalDiffTime
  = time- Data.Fixed.Pico
data UTCTime
  = UTCTime {utctDay :: time-,
             utctDayTime :: DiffTime}
newtype UniversalTime
  = ModJulianDate {getModJulianDate :: Rational}
addUTCTime :: NominalDiffTime -> UTCTime -> UTCTime
diffUTCTime :: UTCTime -> UTCTime -> NominalDiffTime
picosecondsToDiffTime :: Integer -> DiffTime
secondsToDiffTime :: Integer -> DiffTime

there is only one time package installed, so i'm surprised to see any package prefixes at all here

$ ./ghc-6.9.20080514/bin/ghc-pkg.exe find-module Data.Time.\*

but by what system do some things get prefixes and others don't? are there any invisible modules that need the distinction, or is this an output bug?

Change History (5)

comment:1 Changed 7 years ago by simonmar

  • difficulty set to Unknown

When you say ':browse M', GHCi pretends you've imported module M for the purposes of determining what's in scope. Everything not exported by M is out of scope, and in order to be completely unambiguous about which names are meant, GHCi gives the fully-qualified name including the package.

The package prefixes are a bit unfortunate because they aren't valid syntax for one thing. OTOH, there might be no way to refer to the identifier in question at all using just a module qualifier.

I don't really know how to improve this easily. Are you worried about consuming the output of :browse by a tool, or just using it interactively?

comment:2 Changed 7 years ago by claus

  • Type changed from bug to feature request

ah, i see. so it is really telling me that the thing is not in scope, while giving me an indication of what it is that is not in scope.

i first noticed the effect via the type tooltips in my haskellmode plugins for vim, which are derived from interpreting the output of :browse! *Main. now i see that the difference is between

import Prelude()
import Data.Time.Clock(getCurrentTime,UTCTime)

which gives the type of getCurrentTime as GHC.IOBase.IO UTCTime, and

import Prelude()
import Data.Time.Clock(getCurrentTime) --,UTCTime)

which gives the type as GHC.IOBase.IO time-

okay, so there is a system to this. but the presence of the package prefix alone does not always imply "not in scope", does it? perhaps some way of indicating the "not in scope" aspect would be useful (putting it in braces perhaps?).

anyway, i'm changing this to a feature request. it isn't a bug, just a little odd and unexpected, and perhaps someone finds a way to make it less odd, but it isn't high priority.


comment:3 Changed 7 years ago by igloo

  • Milestone set to _|_

comment:4 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.