Who could provide information regarding START_FILE pragma?
The is no word about START_FILE in GHC Pragmas Documentation. Nevertheless it seems to be widely used [1], [2], [3].
Unfortunately ghc 8.2.2 does not compile following code[1].
{-# START_FILE main.hs #-}
main = readFile "file.txt" >>= putStr
{-# START_FILE file.txt #-}
Hello, world!
No, this is an extension specific to School of Haskell Markdown. It's used to provide several "files" in a single Markdown code block.
It's not "widely used" outside of School of Haskell for that reason. When reading such code snippets, simple treat everything after a START_FILE pragma as if it was in a file with the name indicated as the parameter (if it indicates a format like BASE64 you need to put the decoded bytes into the file instead).
This pragma is used by stack templates. You can specify multiple files inside single file with extension .hsfiles by separating files with {-# START_FILE #-} pragma.
stack new PACKAGE_NAME myfiles.hsfiles will create those files (and all directories automatically) according to your layout, if myfiles.hsfiles contains:
{-# START_FILE {{name}}.cabal #-}
name: {{name}}
version: 0.1.0.0
or
{-# START_FILE package.yaml #-}
name: {{name}}
version: 0.1.0.0
See some examples in this repository:
https://github.com/commercialhaskell/stack-templates
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 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.
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).