I saw a Haskell source code, and at the beginning of the source file, it included several things like:
{-# LANGUAGE DeriveFunctor #-}
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE DeriveTraversable #-}
{-# LANGUAGE DeriveFoldable #-}
I know that comments in Haskell stat with {- and end with -}, but this is clearly something else. What's the purpose of this? It seems pretty similar like include statements or macros in C.
The purpose is to enable language extensions. It's a compiler pragma. The GHC compiler supports a lot of language extensions. The GHC manual provides explanation of each extension and examples.
Related
I need to find the length of a trail in Haskell Diagrams.
I've found the function stdArcLength which seems to give me the length. I have no idea how I would convert this into an Int or a Double.
round and floor throws ambigoues errors. How should I go about converting this (N p) (which I don't what is) to a Double?
EDIT: Example and error.
I have a function called mkPathLength :: Int -> Int -> AnimationAttribute which I first try to call like so mkPathLength (stdArcLength l) 0. This gives the following error
Couldn't match expected type ‘Int’ with actual type ‘N p0’
The type variable ‘p0’ is ambiguous
Understandably, I can't pass it directly as an Int, so I try to round it. That gives me this error
Ambiguous type variable ‘p0’ arising from a use of ‘round’
prevents the constraint ‘(RealFrac (N p0))’ from being solved.
Probable fix: use a type annotation to specify what ‘p0’ should be.
Providing a type annotation doesn't seem to work either, but I'm not entirely sure which parts it want me to annonate.
My file has the following extensions:
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NegativeLiterals #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
EDIT v2 Removing "NoMonomorphismRestriction" has solved the issue. I don't even know what it does.
I'm encountering the following hard to understand behavior from GHC-8.2.2
I have some overlapping typeclass instances. No incoherent typeclass instances. There's a certain typeclass instance of the form, roughly,
instance (C f h, C g h) => D1 (D2 f g) h
where C has overlapping instances. When I load my project into stack repl, all is well. The context of this instance is resolved to the instances of C I'm looking for.
If I create a file test.hs which imports a datatype falling under the instance above, all is not well. When I load that into stack repl, and call an operation of D1, then it's clear that the context of the instance of D1 is being resolved to the "wrong" instance of C.
What's especially strange is that if I add test.hs to my project as an exposed module, then reload it into the repl with no other changes, then the context of the instance above is resolved to the "right" instance of C.
I do not see this behavior with GHC-7.10.3, 8.0.1, 8.0.2, or with 8.4.3. Perhaps this is related to this bug?
But I'm not using incoherent instances, which is what that bug seems to involve. I am using a fair number of language extensions in the module where the instance above occurs:
{-#LANGUAGE TypeFamilies, UndecidableInstances, FlexibleInstances, MultiParamTypeClasses, FunctionalDependencies, GADTs, DataKinds, PolyKinds, TypeOperators, PatternSynonyms, RankNTypes, FlexibleContexts, ScopedTypeVariables, DefaultSignatures #-}
I don't yet have a minimal example. A minimal example of the behavior can be found at GHC-Repro. Run test.sh to see the phenomenon. What I would like to know is:
Whether this might conceivably be intended behavior by GHC, and I'm just doing something wrong.
If I am doing something wrong, what I might do to select the "right" instance when importing stuff from my project into other projects.
This issue is now being tracked at: https://ghc.haskell.org/trac/ghc/ticket/15599
There are quite a few alternatives that (subjectively) improve on the standard Haskell Prelude. When developing applications it makes sense to use them, but how to best tell your compiler that?
My ideas:
import qualified Prelude
import MyPrelude
But then HLint complains that importing Prelude qualified is redundant.
{-# LANGUAGE NoImplicitPrelude #-}
import MyPrelude
This seems to work but is rather verbose.
Some kind of global LANGUAGE pragma in the cabal file
Are there other ways? Is there a generally agreed on standard?
If you actually want to import a distinct prelude, then not importing the standard prelude is correct, and hence
{-# LANGUAGE NoImplicitPrelude #-}
import MyPrelude
is the standard way.
I am going through Haskell code to see how I could write similar stream fusion functions and I noticed a funny syntax construct, {-# ... #-}, that I've not come across; so I would like to know what it is and how I can find out how it works:
-- | /O(n)/ Drop elements that do not satisfy the predicate
filter :: Vector v a => (a -> Bool) -> v a -> v a
{-# INLINE filter #-}
filter f = unstream . inplace (MStream.filter f) . stream
More specifically, what does particular line do?
{-# INLINE filter #-}
GHC has a "pragma" system which allows you to specify extra-linguistic information to GHC. In particular, they look like
{-# <NAME> <ARGS...> #-}
The most common you will see are the language extension pragmas which must go at the top of a file and affect the language extensions in effect for the remainder of the file.
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Example where
Normally it ought to be that ignoring a pragma does not affect the meaning of the program. This is broadly true for pragmas like INLINE as they are merely hints to the compiler that this function's body should be inlined wherever it is called in order to open up new optimization opportunities. Haskell semantics gives us guarantees about when such inlining transformations do not change the meaning of the program, thus the choice the compiler makes about whether or not to inline has no effect on the meaning of the program (so long as it doesn't violate the assumptions of those guarantees).
The LANGUAGE pragmas are a bit different in that they specify exactly what language is being written in for the rest of the file. For instance, we typically assume the base language is Haskell98 or Haskell2010 and the LANGUAGE pragmas add extensions such that the language of the file with the headed exemplified earlier is
Haskell2010 + RankNTypes + FlexibleInstances + ScopedTypeVariables
but beyond hinting to the compiler which language is being written these pragma have no further meaning.
The full set of allowable pragma depend upon the compiler being used. GHC's pragmas are listed here (note that this link is for version 7.6.3 while the link in the comments is for 7.0.3). Use of pragmas other than LANGUAGE may be sketchy and platform specific, so learn their use and meaning carefully.
For instance, there's a big debate about whether or not library authors should use INLINE as it tends to suggest a lack of faith in GHC's own inlining heuristics and thus that we should spend more effort tightening those up rather than littering code with manual INLINEs. But that said, INLINE and INLINABLE can have profound impact on tight inner loops if used judiciously.
It's a pragma. It's basically something not expressible in the language standard itself, but still saying something relevant to the compiler.
Some of these pragmas are essentially optional, just e.g. improve performance, hence the comment-like look. In your example, INLINE means the compiler should try hard to not just link to the function in question, but actually "hard-code" it anywhere it's called. This does not in principle change program semantics, but can have quite an impact on performance and memory usage (in particular if combined with extra stream fusion etc. techniques).
I'm getting an error that Constraint is not in scope, when I try to write a simple example,
{-# LANGUAGE UndecidableInstances,
MultiParamTypeClasses,
KindSignatures,
Rank2Types,
ConstraintKinds,
FlexibleInstances,
OverlappingInstances,
TypeFamilies #-}
type family A a :: Constraint
The error is,
> ghci test.hs
[1 of 1] Compiling Main ( test.hs, interpreted )
test.hs:10:20: Not in scope: type constructor or class `Constraint'
Failed, modules loaded: none.
Constraint synonyms seem to work as expected,
type ShowOrd a = (Ord a, Show a)
Thanks in advance.
Your error appears to be caused by Constraint being, unsurprisingly, not in scope. You'll want to import it from GHC.Prim or from GHC.Exts.
It seems a bit odd that enabling ConstraintKinds doesn't bring it into scope automatically, as it does in a 7.3.2 snapshot build I had lying around, but there you go.