I would like to add an extra switch "-XDeriveDataTypeable" to the compiler.
Otherwise, I would like to able to compile Typeable.
Where can i do that in Leksah?
Generally
Here's a editor/ide-agnostic solution to your problem:
For language extensions, you can add this at the top of the source as a compiler pragma, which I prefer anyway:
{-# LANGUAGE DeriveDataTypeable #-}
instead of -XDeriveDataTypeable on the command line
You can pass other command line options to GHC, like this:
{-# OPTIONS_GHC -fno-warn-name-shadowing #-}
In Leksah
Leksah uses cabal for build configuration, so there's no special Leksah magic, that's all standard, but you can use the package editor as a GUI to edit the cabal file.
2/3 of the way down is the Extensions section where you can specify what language extensions you want.
Related
I have the following Visual Studio Code extensions for Haskell installed:
If I use elem in a prefix form:
(elem n primes)
I get a blue squiggly that suggests the infix form:
Is there a way to turn off just this particular hlint rule, hlint(refact:Use infix) just for this file or project?
Yes!
For a single source file, add one of these to the top of the file:
{-# ANN module "HLint: ignore Use infix" #-}
{-# HLINT ignore "Use infix" #-}
{- HLINT ignore "Use infix" -}
For the entire project, create a file .hlint.yaml as follows:
- ignore: {name: Use infix}
You can also run hlint --default > .hlint.yaml from a terminal, which will create a .hlint.yaml file ignoring any hints currently uncorrected in your project.
These are not VS Code specific - they apply wherever hlint is used.
For more information see the HLint manual.
Happy Haskelling!
Is there a way to put {-# LANGUAGE <feature> #-} pragmas in either the:
<project>.cabal, or
stack.yaml
file, to avoid repeating the same header code in every *.hs file of a project?
As #user2407038 said in the comments, you can use the default-extensions field in your <project>.cabal file.
If you wanted to have OverloadStrings and GADTs in all of your modules in the project, you would list it in relevant section of your cabal file (i.e. if you want it for all of your library files, put it in library).
For example:
-- <project>.cabal
...
library
hs-source-dirs: src
default-extensions: GADTs
, OverloadedStrings
...
If you are using a package.yaml configuration file to generate your <project>.cabal file, you can also specify this field there.
-- package.yaml
library:
source-dirs: src
default-extensions:
- OverloadedStrings
- GADTs
exposed-modules:
- MyModule
...
Wow this is annoying. The error message from cabal literally says to use 'extensions:', but you have to use 'default-extensions:'...
When I am developing I like to have -fdefer-type-errors and -XPartialTypeSignatures enabled. Currently I just add
{-# LANGUAGE PartialTypeSignatures #-}
{-# OPTIONS_GHC -fdefer-type-errors #-}
to the top of the file I am working with. However this is not ideal as I often forget to remove these lines once I am done. Is there an option to pass these to intero in emacs?
Updating your cabal file to specify the relevant extensions and ghc-options should work, i.e.:
...
lib
hs-source-dirs: src
ghc-options: -fdefer-type-errors
extensions: PartialTypeSignatures
This can now be archived by setting intero-extra-ghc-options and intero-extra-ghci-options.
I'm following the Yesod book, which states:
But by using the -ddump-splices GHC option, we can get an immediate
look at the generated code. A much cleaned up version of it is:
How would I do this? I've tried compiling my file with ghc -XTemplateHaskell -ddump-splices Page.hs, which leaves the directory as follows:
Page Page.hi Page.hs Page.hs~ Page.o
None of these files, however, contain the intermediate code generated by Template Haskell.
http://www.yesodweb.com/book/basics
Meanwhile the behaviour changed and the -ddump-to-file flag in addition to the -ddump-splices flag causes the splices to be written to a file, see Section 9.26 of the current (GHC 8.2.1) documentation for more details.
On older versions of GHC (I didn't check in which version exactly the behaviour changed), -ddump-splices worked differently:
The -ddump-splices option causes GHC to dump the splices to stderr. Unfortunately, the -ddump-to-file flag doesn't affect splices (I don't know whether that has deeper reasons or is just an oversight), so you need to capture the stderr output to save the splices for later investigation,
ghc -XTemplateHaskell -ddump-splices Page.hs 2> Page.dump-splices
on sufficiently bash-like shells.
In large projects doing this for all modules is problematic.
Fortunately, you can dump per module.
This also works in ghci.
You can add this line to the top of your module
{-# OPTIONS_GHC -ddump-splices #-}
It dumps it to stderr.
{-# OPTIONS_GHC -ddump-to-file #-}
is also usefull which puts the dump in a file next to the module with the prefix .dump-simpl.
See reference: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debugging.html#ghc-flag--ddump-to-file
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debugging.html#ghc-flag--ddump-splices
You can add these as separate lines (for easy copy pasting)
In my cabal file I have a bunch of language extensions enabled. Let's say I have
TemplateHaskell
QuasiQuotes
CPP
Is there a way to start GHCi with these enabled automatically? instead of manually doing
ghci -XTemplateHaskell -XQuasiQuotes -XCPP
Yes, you can use the .ghci file. See section 2.9 in the GHC manual.
~/.ghci
:set -XTemplateHaskell -XQuasiQuotes -XCPP
cabal-ghci was exactly what I wanted.
Specify the extensions in a pragma at the top of the source files:
{-# LANGUAGE TemplateHaskell, QuasiQuotes, CPP #-}
For ghc options that are not within the scope of the language pragma, you can also use the OPTIONS_GHC pragma (and you could write {-# OPTIONS_GHC -XTemplateHaskell -XQuasiQuotes -XCPP #-} (note the lack of commas), but the language pragma is preferred where possible, as it is portable to other compilers that support the extensions).