Sorry for the very basic question: In GHCi, is there a difference between import Library.Name and :m +Library.Name? They seem equivalent, but I assume there's a reason for the alternative syntax.
You're right that import Module and :module + Module are identical, but there are a few reasons for the :module (henceforth abbreviated :m) syntax.
It's older. GHCi really used to just be the inside of an IO do block; now it supports every part of the language, so we can do imports. (It looks like GHCi 6.6.x didn't support import, but GHCi 6.8.1 did; we didn't get full support for top-level declarations until GHCi 7.4.1.)
It lets you import multiple modules at once. :m + M1 M2 M3 is the same as writing import M1, import M2, and import M3 each on a new line.
It lets you un-import modules: :m - M will remove M's contents from what's currently in scope at the prompt.
It lets you import an interpreted module so that you can see the whole scope. This is what happens when you :load File.hs; you find that you're in the module *File, and can e.g. see everything that File imports and even everything that it doesn't export. If you have an interpreted module MI loaded, then you can use :m + M1 *MI M3 to bring M1 and M2 into scope the ordinary way, and MI into scope the special way.
For completeness, though, import syntax does offer us three things that :m doesn't:
Qualified imports. It's much nicer to be able to do import qualified Data.Map as M and use M.lookup than to have to do Data.Map.lookup or suffer ambiguity errors. (Note that every package that's installed is available fully qualified in GHCi, so import qualified Module alone buys you nothing.)
Import lists. Even if I have the functions from Data.Map qualified with M, I can still do import Data.Map (Map) to just bring the type into scope unqualified.
Import hiding. The reverse of the above; maybe I'm writing my own sorting routine, so I can do import Data.List hiding (sort).
You can also check out §2.4.5, "What's really in scope at the prompt?", in the GHC (7.6) user's guide.
You would include import in the source code, which is more general, whereas :m is a ghci - specific command (for convenience).
You can use ghci> :m + Module1 ... ModuleN to load multiple modules. Use - instead of + to unload the module. Because ghci is interactive, I'd stick to :m, unless your workflow is rather: edit your .hs file, save it, and reload it. Then the import would be more suitable (and has more features e.g. qualified imports).
The import directive would also work if you later decide to compile the program using for example ghc. You can selectively import only specific functions: import Data.List (sort) would import only sort, so is pollutes the namespace less.
Related
Hi I am trying to run a custom monad by using prelude as suggested here:Calling a custom monad in haskell using the bind , by using Prelude Control.Monad> runCustomM cm "foo"
However when I try to do the import Control.Monad nothing happens an the prompt type doesn't change. Likewise nothing happens when I use the System.IO as suggested here:
https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/ghci.html
How can I execute the prelude correctly s.t. I can execute my own Monads?
I tried
Loaded package environment from C:\Users\tqx98\AppData\Roaming\ghc\x86_64-mingw32-9.0.1\environments\default
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
ghci> import Control.Monad
ghci> import System.IO
ghci>
The above is more or less all that happens.
When I try to do the import Control.Monad nothing happens an the prompt type doesn't change.
This appears to be the expected behaviour in your version of GHCi, see the documentation of v9.0.1 (contrasting with that of v8.4.2 which you linked). In my experience, the long prompt was quite annoying when importing a lot of modules, so I'd consider it an improvement.
It just be working just fine to call the functions from the imported modules.
I am learning about Haskell. I am importing the Options.Applicative module, like so:
import Options.Applicative ((<>), Parser)
import qualified Options.Applicative as P
However, this returns
Module ‘Options.Applicative’ does not export ‘(<>)’
What is wrong with this? This documentation suggests this should be possible.
You need to import (<>) from either Data.Monoid or Data.Semigroup, as Options.Applicative doesn't actually re-export it. A quick way to verify that is checking the "<" page in the documentation index, which would include (<>) if it was re-exported.
P.S.: While the readme currently on Hackage is slightly misleading indeed, the missing import was already added upstream at GitHub, and so it will be fixed when the next version of the package is released.
(<>) is in Data.Monoid, not Options.Applicative. It's an infix synonym for mappend.
I have decided to use my own Prelude for a larger project (containing some libraries and some executables). The Prelude doesn't export some partial functions and exports some common functions (i.e. from Control.Monad etc.). However, I am fighting with the way how to do it. I have tried:
use base-noprelude. Create Prelude.hs in module my-common-module.
Same as above, but in the my-common-module create My.Prelude instead. In every other module create a directory 'prelude', put it into hs-source-dirs cabal section, create a file prelude/Prelude.hs with import My.Prelude
The problem is that in 1) I cannot just run ghci, as I get conflicting base and my-common-module. In 2) ghci works, cabal repl somehow doesn't as it fails mysteriously with 'attempting to use module ‘Prelude’ (prelude/Prelude.hs) which is not loaded'. Additionally, base-noprelude doesn't seem to like ghcjs, which I want to use for part of the project (code sharing).
It seems to me the only way currently is to start each and every file with:
import Prelude ()
import My.Prelude
or
{-# LANGUAGE NoImplicitPrelude #-} -- or extensions: NoImplicitPrelude in .cabal
...
import My.Prelude
The 'extensions: NoImplicitPrelude' option seems to me best as it requires every file to import My.Prelude otherwise it won't work. Am I missing some obvious way that would achieve custom Prelude and at the same time work with cabal repl and ghcjs?
Update: base-noprelude works with GHCJS when I manually remove the reexport of GHC.Event.
Update: Ok, I spent some time with this and I should have spent more. It seems to me that 1) is the right way to go. cabal repl works (thanks Yuras), ghci must be loaded with ghci -hide-package base and works too.
I ended up with this setup that seems to work:
Create a special package my-prelude. This package exports the Prelude, can contain other modules, it can depend on base. You may need to use {-# LANGUAGE NoImplicitPrelude #-} in some modules to avoid circular dependencies. E.g. you may want to have some orphan instances defined and exported by your custom Prelude in separate files (e.g. Orphans.Lib_aeson), these files need the NoImplicitPrelude.
In your main project, libraries etc. change the dependencies in cabal from base to base-noprelude, my-prelude.
What works:
cabal repl
ghci/runghc works, but you have to start it with ghci -hide-package base; otherwise there will be conflict between base and my-prelude
What does not work:
cabal repl in the my-prelude package.
Does it is possible to use the equivalent of "import qualified" in GHCI with our OWN module? Something like :m + qualified Data.List which of course doesn't work.
Thanks.
Just type import qualified Data.Text or import qualified Data.Text as T inside ghci, just as you would do inside your code.
I don't know of a pretty way to do what you want, but you could fake it with something like this:
First, use :load My/Module.hs to load your module.
Use :module - My.Module to bring it out of scope.
(Optional.) Use import qualified My.Module as MM to bring it into scope qualified.
Every module that GHCi knows about is automatically available fully qualified, so after step 2, My.Module.value will work fine. Step 3 is only necessary if you want to use a shorter prefix.
If you want to load multiple files at once, :load can do that too;
:load My/Module1.hs My/Module2.hs ... My/ModuleN.hs
will work fine. It will put you in the scope of *My.Module1, and then My.Module2 … My.ModuleN will all be available fully qualified as mentioned above.
For more about GHCi, you can always check the GHC User's Guide, Ch. 2: "Using GHCi"; particularly relevant sections are §2.2, "Loading source files" and §2.4.5, "What's really in scope at the prompt?".
I want to write a module which re-exports some module it had imported qualified. Something like this:
module Foo.A
( module Foo.B
, module Foo.C
) where
import qualified Foo.B
import qualified Foo.C
-- bunch of code using Foo.B and Foo.C here
This looks like it ought to work; however, GHC prints warnings about the exports:
Foo/A.hs:2:5:
Warning: the export item `module Foo.B' exports nothing
Foo/A.hs:3:5:
Warning: the export item `module Foo.C' exports nothing
And GHCI refuses to load exports from them.
I can solve this by making the imports unqualified, but then naming conflicts are likely to arise between those imports and the main module code.
Is there any way to make GHC export these modules?
No, that isn't just a limitation of GHC, it's the way import
and export is designed to work in Haskell.
A module only has
control of its own namespace - it can't affect what people
can see from other namespaces. A module
"re-export" is just a shorthand to say "export all
of the symbols in my own namespace that happen to have
been imported here from that other module". But symbols
that you imported qualified aren't really in your own
namespace.
If you want to export two different symbols that have
the same name, you won't be able to do it from one module.
Split the module into two, and export each version from
a different module.
This limitation is also a convenience when the importing module is meant to re-declare some names in the imported module, based on declarations of a qualified import. For instance:
module MyPrelude (succ, module Prelude) where
import qualified Prelude as P (succ)
import Prelude hiding (succ)
succ :: ...
succ = ... P.succ ...
this idiom would be really hard to express without a lot of verbosity otherwise. Also, ask your self "would this make sense without hierarchical modules?". If not, then this is very ghc specific, and what is actually going on when referencing a hierarchical module name from an expression is not hierarchical at all.
As to why you are able to reexport individual symbols qualified by some module name you did not import, that seems like a kludge to get heirarchical modules to work heirachically in ghc. Gaining Foo.B qualified symbols when importing Foo.A is magical, and I think its because The name Foo is no more an actual heirachical ancestor than Foo.A, but the intended use of exporting things with alternate qualification is in cases where its used from Foo. I don't think this behavior makes sense at all without GHC extensions, so I am going to take a wild guess that its GHC specific.