Compiling the following Haskell program with GHC 6.12.1 yields an error:
{-# LANGUAGE NoImplicitPrelude #-}
module Example where
import Prelude(Integer, fromInteger, (==))
f :: Integer -> Integer
f n
| n == 0 = 0
Namely:
example.hs:9:6: Not in scope: `>>'
The error goes away when I change the import statement to:
import Prelude(Integer, fromInteger, (==), (>>))
This makes sense. What I don't understand, however, why there is an error in the first place. My program doesn't seem to make use of any Monad, while >> is one of the Monad operators.
I don't know the root cause of this problem, but if you compile your code with -ddump-rn-trace option on, you can see that the compiler for some reason puts (>>) into a list of definitions used, something like that:
finish Dus [(Nothing, [(314, Integer)]),
(Just [(rdd, f)], [(01D, >>), (01E, fromInteger), (01L, ==)]),
(Nothing, [])]
Most certainly it is a bug in GHC 6.12.1
This is a bug in ghc. You should report it.
I can imagine the compiler checks to see if >> is present (which it needs for compilation of do-blocks), no matter if do occurs in your code.
(But then, it should also complain about >>=)
Related
I am trying to declare a function in Haskell GHCi as
fact :: Int -> Int
But I am getting this error - error: parse error on input `->'
I do not understand why this is happening. Can anyone please explain it to me? Thanks.
First off, it looks like you're using a pretty old version of GHC. In newer versions, the GHCi syntax has been relaxed a bit.
But still: what you type in GHCi does not have the same rules as what you write in a Haskell source file. Specifically, the GHCi prompt is essentially an IO monad chain evaluator, the reason being that you can write stuff like
Prelude> putStrLn "Hello"
Hello
or
Prelude> readFile "test.txt"
"fubar\nbaz"
and actually have it execute right there. By contrast, in a Haskell source file, you only declare bindings, and these can then be invoked in the main action or a GHCi session.
But in this case, you want to declare a binding within GHCi itself. You can do that too, but it's a bit awkward, basically you need to start with let and then squeeze everything in a single line:
Prelude> let fact :: Int -> Int; fact n = product [1..n]
Actually, newer GHCi version allow you to omit the let, and you can have multiple-line definitions by using a special bracket syntax:
Prelude> :{
Prelude| fact :: Int -> Int
Prelude| fact n = product [1..n]
Prelude| :}
but I would recommend against this. If you actually have some bigger definitions, better put them in a proper Haskell source and load that into GHCi.
How do I lookup type operator name? This does not work:
IssueTH.hs:
{-# LANGUAGE TemplateHaskell #-}
module IssueTH where
import Language.Haskell.TH
f :: Q [Dec]
f = do
Just n <- lookupTypeName "GHC.TypeLits.*"
return []
Issue.hs:
{-# LANGUAGE TemplateHaskell #-}
module Issue where
import IssueTH
$f
ghc Issue.hs fails with message:
Pattern match failure in do expression at IssueTH.hs
Replacing "GHC.TypeLits.*" with "GHC.TypeLits.(*)" or "*" doesn't work either.
I guess I have enough now for a brief answer. Alas I only found the reason for your problem, but not how to solve it.
My testing shows that lookupTypeName does support type operators, but only if they start with :.
Originally this was a requirement, in analogy with infix data constructors, but this was lifted to allow things like the arithmetical type operators in GHC.TypeLits. (The downside is that you can no longer have type operator variables, as were once popular for things like Arrow code.)
Presumably lookupTypeName was not updated to take this into account, and I have filed a bug report for this.
EDIT: A fix for this has finally been made, and should be in the upcoming GHC 8.2.1.
I've recently come across a bot on Twitter named EmojiHaskell, that claims to tweet 'interpretable Haskell code with emoji variable names'. A particular Tweet caught my attention, as it looked like malformed syntax to me, so I decided to take a closer look. So far I've produced the following code:
module Main where
🙏 :: [🍳] -> Maybe 🍳
🙏 [] = Nothing
🙏 (👽:as) = Just 👽
main = print $ 🙏 "♥"
Since I've used λ on occasion in my Haskell code, I expected this code to work, but it appears that GHC doesn't like the emoji at all.
With $ runhaskell Main.hs I get:
Main.hs:4:1: parse error on input ‘🙏’
I've already had a look at the UnicodeSyntax extension,
and tried to only use some or single emoji instead of all of them to see if a certain one provokes the problem.
Now my question is this:
Is there currently a Haskell compiler that would accept the code?
Can I get GHC to work with this code somehow?
That code is not valid haskell. The reason is that 🙏 (like, probably, all Emojis) is a symbol character:
Prelude> import Data.Char
Prelude Data.Char> generalCategory '🙏'
OtherSymbol
But you can still use them like any other symbol, namely as an operator:
Prelude Data.Char> let (🙏) = (+)
Prelude Data.Char> 32 🙏 42
74
Furthermore, as user3237465 pointed out, if you use the prefix syntax for operators, i.e. put it in parentheses, you can even use it like any other symbol:
(🙏) :: [a] -> Maybe a
(🙏) [] = Nothing
(🙏) ((👽):as) = Just (👽)
main = print $ (🙏) "♥"
This is almost the example in the original post. Unfortunately, this trick does not work for the type variable. The the documentation is worded a bit unfortunately, but in fact symbols are never type variables and always type constructors
I'm using GHCi 7.0.3 with the following program that implements type-level list:
{-# LANGUAGE TypeOperators #-}
data True
data False
-- List
data Nil
data Cons x xs
-- Type-level infix operator must begin with ':'
data x ::: xs
infixr 5 ::: -- set precedence level to 5 (tight)
It compiles, but when I test it with:
:t (undefined :: True:::Nil)
(what's the type of undefined when cast to type True:::Nil?) I get this error:
Illegal operator `:::' in type `True ::: Nil'
Use -XTypeOperators to allow operators in types
And indeed, when I start GHCi with the flag
-XTypeOperators
I get the expected result:
(undefined :: True ::: Nil) :: True ::: Nil
My question is: Why doesn't the equivalent pragma work:
{-# LANGUAGE TypeOperators #-}
Edit: If pragmas don't extend to GHCi environment than I have another puzzle. I tried this program:
class And b1 b2 b | b1 b2 -> b where
andf :: b1 -> b2 -> b
-- truth table
instance And True True True where andf = undefined
instance And True False False where andf = undefined
instance And False True False where andf = undefined
instance And False False False where andf = undefined
It required the following pragmas:
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
But once compiled, I could use it in GHCi:
*Main> :t andf (undefined::True) (undefined::False)
andf (undefined::True) (undefined::False) :: False
I guess in the list case the interpreter couldn't even parse the expression with type-level operator :::, whereas in the case of multiparameter classes the command line was parseable. But, come to think of it, GHCi performed type inference using multi-parameter classes and functional dependencies, didn't it? This type inference is done in GHCi, and not by calling some function in the compiled code, right?
The other answers are correct about enabling the extension in GHCi, either from the GHCi prompt or as a flag when starting GHCi. There is a third option, however--you can create a .ghci file that will be loaded and run every time you start GHCi, and use that to enable the extension automatically. Particularly for things like TypeOperators, where there's very little harm in having it enabled, it's nicely convenient.
For example, here's what mine looks like right now:
:set prompt "∀x. x ⊢ "
:set -XTypeOperators
import Control.Monad
import Control.Applicative
import Control.Arrow
The .ghci file goes in whatever your system's standard location is for such files.
To answer your extended question: The code in question works in GHCi roughly because it would also work if used in another module, which imported the module using the pragmas but didn't enable them itself. GHC is more than capable of enabling extensions on a per-module basis, even when the exported definitions couldn't possibly make sense without an extension, or have inferred types that require it.
The distinction is a little fuzzy in GHCi because it also puts non-exported definitions from the module in scope, but in general anything that would work if used from another module will also work at the GHCi prompt.
Your pragma is correct; the problem is that you're trying to use it from within GHCi, which doesn't inherit the extensions of the loaded module,1 but does pass the options it's given to GHC to compile the files you list (which is why it has the same effect as the pragma).
You should keep the pragma, and either pass -XTypeOperators when you start GHCi, or enable it after loading the file as follows:
GHCi> :set -XTypeOperators
1 Which could be very undesirable, and probably impossible in many cases, for e.g. loading compiled modules.
The LANGUAGE pragma works for the source file, it is not propagated to the ghci-prompt. Since it is possible to have conflicting pragmas in multiple source files of a project, source pragmas cannot by default propagate to the ghci-prompt. It would be possible to have the pragmas from *modules effective at the prompt, I'm not sure, but I think it is pondered to implement that, anyway, so far, it's not implemented, so you need to set the extensions for ghci explicitly.
I'm beginning Haskell... I tried to write the following trivial function in two different ways, letting Haskell decide the types, and the type system does something different in each case. What is the explanation for that behavior?
Prelude> let f x = 2 * x
Prelude> let g = (2*)
Prelude> :info f
f :: Num a => a -> a -- Defined at <interactive>:1:5
Prelude> :info g
g :: Integer -> Integer -- Defined at <interactive>:1:5
Thanks!
This is known as the monomorphism restriction.
Basically, it means that top-level bindings that look like x = are forced to be non-polymorphic, unless you specify a type signature. Bindings with arguments, i.e. f x = are not affected. See the link for details as to why this restriction exists.
Usually, you get an error message when the restriction is applied, but in this case GHCi is able to use type defaulting to change the type Num a => a to Integer.
The easiest way to dodge it is to either use an explicit type signature, or put
{-# LANGUAGE NoMonomorphismRestriction #-}
at the top of your module, or run GHCi with -XNoMonomorphismRestriction.
As others have pointed out, this is caused by something called the "Monomorphism Restriction".
MR can be useful for writers of Haskell compilers, and there is controversy about whether or not it is worthwhile to have in the language in general. But there is one thing everyone agrees: at the GHCi prompt, MR is nothing but a nuisance.
MR will probably be turned off by default in this context in an upcoming version of GHC. For now, you should disable it in GHCi by creating a text file called ".ghci" in your home directory that contains a line like this:
:set -XNoMonomorphismRestriction
Because the definition of g doesn't explicitly name its arguments, you run into the monomorphism restriction, preventing g from being polymorphic and (in this case) causing GHC to default to Integer.