I'm trying to use Format library and the fmt function. I'm getting the error Variable not in scope: fmt :: t1 -> Text.
I'm trying to find the correct import module but can't seem to get it right. I've followed this https://hackage.haskell.org/package/fmt-0.6.3.0/docs/Fmt.html, and I have added {-# LANGUAGE OverloadedStrings #-} and import Fmt at the top of my module, but then get Could not find module ‘Fmt’
The function I'm using is:
--This uses the Format library and the fmt function. It is a formatting library. in this case it attaches a name (msg) to a list(of Text), line by line.
allWordsReport :: String -> [Text] -> Text
allWordsReport msg words =
fmt $ nameF (fromString msg) $ unlinesF words
I'm struggling with the imports a lot for Haskell. Is there an easy way to find what I need to use, as it seems to be more difficult to find documentation for stuff than other languages.
Are you using stack, cabal or other as your build environment? If you are using cabal primarily, one issue might be not having the library installed in the way GHC needs it. Since I am not building production code and just use Haskell to learn programming concepts, I only use cabal and only have one environment. So for me, I did the below to get it working.
cabal install fmt --lib
If you are do things correctly for packaging, then, as noted by Sridhar, you should use dependency information in cabal or stack configuration files.
Related
I am new to Haskell, I am thinking to do a small project of processing the spreadsheet data to improve my Haskell. However I don't know how to import the module needed which is the Data.List.Split so that I can split the data.
Not sure if import like this is correct, I am not using cabal but stack.
I added the extra-deps : [split-0.2.3.4] in my .yaml file but still it does not work, it still show could not find Data.List.Split module.
Thank you.
Here is the error I get
I finally solved it. Simply add "- split == 0.2.3.4" in the package.yaml file "dependencies:" section. Then do the repl again by using "stack ghci" in the command prompt.
Now I am able to use the splitOn function from the Data.List.Split module.
I am getting acquainted to Haskell, currently writing my third "homework" to some course I found on the web. The homework assignment needs to be presented* in a file, named Golf.hs, starting with module Golf where. All well and good, this seems to be idiomatic in the language.
However, I am used to python modules ending in if __name__ == "__main__:, where one can put tests over the module, including during module development.ghc doesn't seem happy with such an approach:
$ ghc Golf.hs -o Golf && ./Golf
<no location info>: error:
output was redirected with -o, but no output will be generated
Even though using cabal seems to be the norm, I would like to also understand the raw command-line invocations, that make programs work. ghci seems to be another approach to testing newly written code, yet reloading modules is peta. What is the easiest way to write some invocations of my functions with predefined test data and observe on stdout the result?
* - for students, who actually attend the course, I just follow the lecture notes and strive to complete the homeworks
Golf2.hs:
{-# OPTIONS_GHC -Wall #-}
module Golf2 where
foo :: Int -> Int
foo n = 42
main = putStr "Hello"
The output:
$ ghc Golf2.hs -o Golf2
[1 of 1] Compiling Golf ( Golf2.hs, Golf2.o )
Golf2.hs:6:5: warning: [-Wunused-matches] Defined but not used: ‘n’
Golf2.hs:8:1: warning: [-Wmissing-signatures]
Top-level binding with no type signature: main :: IO ()
<no location info>: error:
output was redirected with -o, but no output will be generated
because there is no Main module.
ghci is a really useful tool for learning!
When you only have one module, it's very easy, too. Start ghci, then :l Golf.hs. This will load your file. Then you'll be able to type foo 342 and see "42" displayed, or main and see "hello". You can edit the file, then use :reload or :r to load your changes. Real World Haskell has a good intro to using ghci.
This is a little easier than using ghc or tools like cabal, and all you really need while you're learning the very basics.
If you want to use ghc-the-compiler (instead of its interactive variant ghci), you might use the -main-is option.
From the docs:
-main-is⟨thing⟩
The normal rule in Haskell is that your program must supply a main function in module Main. When testing, it is often convenient to
change which function is the “main” one, and the -main-is flag allows
you to do so. The ⟨thing⟩ can be one of:
A lower-case identifier foo. GHC assumes that the main function is Main.foo.
A module name A. GHC assumes that the main function is A.main.
A qualified name A.foo. GHC assumes that the main function is A.foo.
So, try ghc -main-is Golf2 Golf2.hs -o Golf2 && ./Golf2.
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.
I want to enhance flycheck-haskell's support for auto-configuring flycheck from your .cabal file.
To do this autoconfiguration, flycheck uses a helper file whose original strategy was to read the .cabal file and use flattenPackageDescription. This was simple, but does not respect conditional expressions, which can cause problems with, e.g. not needing bytestring-builder when using newer version of the bytestring package.
The appropriate interface to use would seem to be finalizePackageDescription. This does work...but its type signature changed between 1.20 and 1.22---now, instead of taking a CompilerId, it now takes a CompilerInfo. Yet I would like to provide consistent support across this API change.
While the solution for this is generally to use CPP macros, those macros are provided by Cabal itself, and flycheck is simply invoking the helper file with runhaskell, so we don't have access to them.
The only option I can think of would be to create another helper to first get the Cabal version information, and then construct appropriate CPP settings for our runhaskell invocation so we can do things that way. That should work, but seems like a hack.
So I'm here looking for other options that would allow me to support both versions of the interface, without having to resort to CPP.
The code in question is a call to Distribution.PackageDescription.Configuration.finalizePackageDescription, like so:
case finalizePackageDescription [] (const True) buildPlatform buildCompilerId [] genericDesc' of
Left e -> putStrLn $ "Issue with package configuration\n" ++ show e
Right (pkgDesc, _) -> print (dumpPackageDescription pkgDesc cabalFile)
The problem is that the fourth parameter, buildCompilerId changed type from CompilerId to CompilerInfo.
What I have implemented---though I would be happy to consider a more self-contained option---is a helper that spits out -DuseCompilerInfo (as an s-expr, since we're dealing with Emacs) if it's a sufficiently recent version of Cabal:
import Data.Version (Version (Version))
import Distribution.Simple.Utils (cabalVersion)
main :: IO ()
main =
putStrLn $ if cabalVersion >= Version [1,22] []
then "(\"-DuseCompilerInfo\")"
else "()"
The original helper is then run with the flag, and conditionally imports the new structures, as well as having the following conditional code just before the case statement above:
#ifdef useCompilerInfo
buildCompilerId = unknownCompilerInfo (CompilerId buildCompilerFlavor compilerVersion) NoAbiTag
#else
buildCompilerId = CompilerId buildCompilerFlavor compilerVersion
#endif
It's not beautiful, but it works.
What is the best/correct practice to specify version within your source code tree?
What I want is, for instance, to put VERSION file in the top level of the source tree and get the "version" function to read it.
There is a version section in the cabal file. Is it possible to read it from my source by "help" or "version" functions?
What is the correct practice of specifying the version in one place and making it available globaly?
P.S. Are there any functions in the Cabal library that allow you to pull any section from the cabal file and present it in your source? Then I could simply pull the version section from the cabal file.
-- UPDATE --
Thank you Thomas for an nice piece of knowledge about the Pathes_x module.
Just wanted to add that, apparently, I don't need to put anything into my cabal file. Everything just works without it. All I needed was to import the Pathes_X as you sugested.
Also, I needed to import Data.Version to get the showVersion function to properly format/print the Version data type. So at the end I get something like this:
import Paths_kvman
import Data.Version
runVersion _ = putStrLn ("Version: " ++ (showVersion version))
Now, all I need is to change the version number in the cabal file to propagade it all over my source. Exactly what I needed. Thanks.
Cabal automatically generates a module for each package named Paths_packagename. Just import this package and look at the version value it exports.
Edit: For example:
module Data.Blah where
import Paths_t
func :: IO ()
func = print version
And an example run:
> func
Version {versionBranch = [0,1], versionTags = []}
Be sure to put Paths_packagename in your Other-Modules section of the cabal file.
Best practice is to put the version number in your cabal file, as you have already noted.
I am not aware of any good practices by which you can maintain a single point of truth about the version, yet make the number available both to cabal and to your application.
I would recommend a single file Version.hs in the sources with these contents:
module Version
where
version :: String
version = "3.14159"
You could then, if you wished, use some kind of script to update the cabal file with this number, but I don't know how to do this from within cabal itself.
This strategy will work only for application packages; if you are building a library, you'll need to give some thought to where in the namespace of hierarchical modules your Version.hs will go.
On the whole, I suspect the game is not worth the candle.
P.S. The version number should be immutable, so you want a value, not a function.