error when building haddock-api-2.24.0 with cabal - ghc

I tried to install haddock-api-2.24.0 package with cabal (on archlinux) but it failed:
➜ ~ cabal install haddock-api-2.24.0
Resolving dependencies...
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
- haddock-api-2.24.0 (lib) (requires build)
Starting haddock-api-2.24.0 (lib)
Building haddock-api-2.24.0 (lib)
Failed to build haddock-api-2.24.0.
Build log (
/home/kaga/.cabal/logs/ghc-8.10.4/haddock-api-2.24.0-385d0485d7052616aeee1dc25445b810e8e57ae43c803a5d5b3e62f2da8892e0.log
):
......
[11 of 40] Compiling Haddock.GhcUtils ( src/Haddock/GhcUtils.hs, dist/build/Haddock/GhcUtils.o, dist/build/Haddock/GhcUtils.dyn_o )
src/Haddock/GhcUtils.hs:60:42: error:
• Could not deduce: p ~ GhcPass p0
from the context: (SrcSpanLess (LPat p) ~ Pat p,
HasSrcSpan (LPat p))
bound by the type signature for:
getMainDeclBinder :: forall p.
(SrcSpanLess (LPat p) ~ Pat p, HasSrcSpan (LPat p)) =>
HsDecl p -> [IdP p]
at src/Haddock/GhcUtils.hs:(58,1)-(59,40)
‘p’ is a rigid type variable bound by
the type signature for:
getMainDeclBinder :: forall p.
(SrcSpanLess (LPat p) ~ Pat p, HasSrcSpan (LPat p)) =>
HsDecl p -> [IdP p]
at src/Haddock/GhcUtils.hs:(58,1)-(59,40)
Expected type: TyClDecl (GhcPass p0)
Actual type: TyClDecl p
• In the first argument of ‘tcdName’, namely ‘d’
In the expression: tcdName d
In the expression: [tcdName d]
• Relevant bindings include
d :: TyClDecl p (bound at src/Haddock/GhcUtils.hs:60:28)
getMainDeclBinder :: HsDecl p -> [IdP p]
(bound at src/Haddock/GhcUtils.hs:60:1)
|
60 | getMainDeclBinder (TyClD _ d) = [tcdName d]
| ^
I've just begun to learn Haskell so I don't know what's going on here...
It seems like some serious error.
What should I do to get it fixed?

Related

Why does Idris 2 fail to resolve constraints with function composition in this trivial example?

I have encountered a problem with some code I am trying to write in Idris 2. I would like to resolve this issue, but more importantly, I wish to understand it more deeply and develop some skills in diagnosing such issues in general.
I have distilled the problem to the following relatively trivial example:
data D : Nat -> Type where
V : (n : Nat) -> D n
d : (n : Nat) -> D n
d n = V n
f : D n -> String
f (V n) = show n
t : Nat -> String
t = f . d
The definition of t fails type checking with the following output:
Error: While processing right hand side of t. Can't solve constraint between: ?n [no locals in scope] and n.
Test:11:9--11:10
07 | f : D n -> String
08 | f (V n) = show n
09 |
10 | t : Nat -> String
11 | t = f . d
Some experimentation has revealed that the following alternative definitions for t also fail type checking:
t : Nat -> String
t n = (f . d) n
t : Nat -> String
t = \n => (f . d) n
While these alternatives type check successfully:
t : Nat -> String
t n = f (d n)
t : Nat -> String
t = \n => f (d n)
I am endeavouring to learn Idris (for the second time), and so while I could move on with the definitions which don't involve function composition, I would like to improve my understanding.
It seems to me that the definitions which pass type checking are simply syntactic alternatives with identical semantics and behaviour, and I don't understand why the function composition definitions fail type checking. I would also like to understand the particular error message the type checker reports, so that I can deepen my understanding and resolve similar type checking errors in the future.
I have a few broad questions:
How should I interpret the error reported by the type checker in this example, and how can I gather more information about the ?n and n types mentioned? I particularly welcome any advice or tips on how to go about understanding and resolving such an error (teach a man to fish, as the saying goes).
Why do the definitions involving function composition fail type checking?
What is the best solution for this example? Should I just use a definition which does not involve function composition? Is there a better alternative?
Let look at the types involved
Prelude.. : (b -> c ) -> (a -> b ) -> a -> c
f : D n -> String
d : (n : Nat) -> D n
The problem is:
(a -> b )
(n : Nat) -> D n
cannot be unified because (a -> b) does not allow the value of the argument to determine the type of return value.

Can't disambiguate name: Prelude.List.++, Prelude.Strings.++ error in Idris

Currently I am trying to create a function that takes the type of
(a -> a -> a) as a parameter in Idris and the right function to do is the ++ command for lists in idris unfortunately I am getting this error
ListMonoid : (A : Type) -> RawMonoid
ListMonoid A = (A ** ([], (++)) )
When checking right hand side of ListMonoid with expected type
RawMonoid
Can't disambiguate name: Prelude.List.++, Prelude.Strings.++
Raw Monoid is a data type below
RawMonoid : Type
RawMonoid = (M ** (M , M -> M -> M))
infixl 6 &
It seems to me that it does not know which ++ to use, is there a way to specify this in the call?
You can qualify the reference to (++), e.g.
ListMonoid A = (A ** ([], List.(++)) )
And there's also the with keyword, which takes a module name as its first argument - it basically means, "in the following expression, look in this module first to resolve names", e.g.
ListMonoid A = (A ** ([], with List (++)) )
However, both of those give me the following type error with your code:
Type mismatch between
List a -> List a -> List a (Type of (++))
and
A -> A -> A (Expected type)
If I write:
ListMonoid A = (List A ** ([], (++)) )
It's able to pick out the correct (++) based on the surrounding type constraints.

Function cannot use type inference, but I don't understand why

So here is my goofy sandbox to play with Applicatives in PureScript
module Main where
import Debug.Trace
data Foo a
= Foo a
instance showFoo :: (Show a) => Show (Foo a) where
show (Foo a) = "I pity da (Foo " ++ (show a) ++ ")"
instance functorFoo :: Functor Foo where
(<$>) f (Foo a) = Foo (f a)
instance applyFoo :: Apply Foo where
(<*>) (Foo a) (Foo b) = Foo (a b)
m :: Number -> Number -> Number -> Number
m x y z = x * y - z
main = trace <<< show $ m <$> Foo 14
<*> Foo 2
<*> Foo 5
The above works fine, but if I remove:
m :: Number -> Number -> Number -> Number
it does not compile
Error at pure.purs line 18, column 1:
Error in declaration m
No instance found for Prelude.Num u1150
However (+) and (-) are both of type
forall a. (Prelude.Num a) => a -> a -> a
Why can't Number be inferred?
The reality is that when learning PureScript and coming from a dynamic language (JavaScript), I run into type errors frequently. Developing skills in diagnosing and understanding these errors is challenging without a grasp of when inference can occur and when it can't. Otherwise I will have to write types every single time in order to feel confident in my code (lameness).
This is because at the moment the compiler can't infer typeclass constraints, and as you noted the arithmetic operators are all defined in the Num typeclass.
The type that would be inferred for m (if the compiler could) would be something like:
m :: forall a. (Num a) => a -> a -> a -> a
On your second point typing top level declarations is considered good style anyway, as it helps to document your code: see here for a fuller explanation.

Conduits - multiple "attempts" into one Source

I am trying to do the following:
sourceIRC
:: (MonadBaseControl IO m, MonadLogger m)
=> NetworkSettings
-> Producer (ConnectionT m) Message
sourceIRC networkSettings = do
withConnectionForever networkSettings $ \socket -> do
bracket (liftBase $ Network.socketToHandle socket IO.ReadWriteMode)
(\handle -> liftBase $ IO.hClose handle)
(\handle -> do
mvar <- newMVar False
bracket (fork $ do
threadDelay 5000000
_ <- swapMVar mvar True
return ())
(killThread)
(\_ -> runConnectionT handle (sourceHandle handle))
takeMVar mvar)
As you can see, I am trying to create a Producer in terms of a primitive withConnectionForever. That primitive is of type:
withConnectionForever
:: (MonadBaseControl IO m, MonadLogger m)
=> NetworkSettings
-> (Network.Socket -> m Bool)
-> m ()
As you can imagine, I am getting an error message on compilation! It is:
Haskell/IRC.hs:128:54:
Couldn't match expected type `ConnectionT m0 a0'
with actual type `ConduitM i0 ByteString.ByteString m1 ()'
In the return type of a call of `sourceHandle'
In the second argument of `runConnectionT', namely
`(sourceHandle handle)'
In the expression: runConnectionT handle (sourceHandle handle)
Now, I know that the type of the call to withConnectionForever is not obviously a conduit, but I had hoped that it could manage to be one, by virtue of the fact that a conduit is also a monad and withConnectionForever uses a free monad instead of a hardcoded one. My understanding of what the message is trying to communicate is that that's not happening, and I'd like to know why and what I can do about it.
Here, for completeness, is the source of the primitive:
withConnectionForever
:: (MonadBaseControl IO m, MonadLogger m)
=> NetworkSettings
-> (Network.Socket -> m Bool)
-> m ()
withConnectionForever networkSettings action = do
let loop nFailures = do
maybeSocket <- newConnection networkSettings
case maybeSocket of
Nothing -> return ()
Just socket -> do
terminatedNormally <- action socket
if terminatedNormally
then loop 0
else do
exponentTwiddle <- liftBase $ Random.randomRIO (0, 100)
let exponent =
1.25 + fromIntegral (exponentTwiddle - 50) / 100.0
delay = floor $ 1000000.0 *
((0.5 ** (fromIntegral nFailures * negate exponent))
- 1.0 :: Double)
$(logInfo) (Text.concat
["Abnormal disconnection from the network ",
networkSettingsName networkSettings,
"; pausing attempts for ",
Text.pack $ show $ fromIntegral delay / 1000000.0,
" seconds..."])
liftBase $ threadDelay delay
loop (nFailures + 1)
loop 0
I'd really prefer not to rewrite the primitive, unless it can be done in minimally invasive fashion, but I suppose that's on the table.
Thanks in advance!
The relevant thing to do was
(\_ -> transPipe (runConnectionT handle) (sourceHandle handle))
instead of
(\_ -> runConnectionT handle (sourceHandle handle))
Thanks for your time! :D

Haskell Returns only Numerator of Division (Sometimes)

I have two functions:
calctvd :: [Perk] -> [Perk] -> Perk -> Double
calctvd ps fs p = (fromIntegral(tvn) / fromIntegral(points)) :: Double
where
tvn = calctvn ps fs p
points = length $ [i | i <- perkAndPreqs ps p, i `notElem` fs]
The above function always succeeds in returning the double that I would expect. The important line is the division (fromIntegral(tvn) / fromIntegral(points)). The function calctvn (not shown here) and the variable points are always integers, so fromIntegral() is necessary.
updatetvd :: [Perk] -> [Perk] -> [Perk]
updatetvd [] _ = []
updatetvd ps fs
--If p is in the list of elements already taken, then do not update it
| p `elem` fs = [p] ++ updatetvd (tail ps) fs
--Otherwise, update the tvd value
| otherwise = [PerkImpl (tvd, school, skill, name, def, preqstr, pref)] ++ updatetvd (tail ps) fs
where
p = head ps
PerkImpl (_, school, skill, name, def, preqstr, pref) = p
tvd = calctvd ps fs p
Essentially, this second function should just insert the value of the first function into a list. However, it only inserts the numerator of the term (fromIntegral(tvn) / fromIntegral(points)). I proved this by changing that line in calctvd to 3 / fromIntegral(points). With this, calctvd still returned the correctly divided double, whereas updatetvd always inserted a value of 3.0. It is as if Haskell does not evaluate the denominator if calctvd is called from inside updatetvd.
Update 1:
However, it appears that this oddity relies on some complexity in the above two functions. I tried to break it down into a simple example:
testcalctvd :: Double
testcalctvd = fromIntegral(3) / fromIntegral(4) :: Double
testupdatetvd :: Double
testupdatetvd = testcalctvd
However, both testcalctvd and testupdatetvd return the correct 0.75.
Update 2:
Here is an example straight from Terminal, using the test term 3 / fromIntegral(points):
> calctvd initial [] i17
0.6 {This is 3/5, because i17 has 5 points}
> updatetvd initial []
[...3.0...] {This is just the numerator 3}
Update 3:
Here is the perkAndPreqs function, which is probably the culprit, but I am not sure how much sense it will make:
--Take a perk and return a list of that perk and all of its pre-requisites
perkAndPreqs :: [Perk] -> Perk -> [Perk]
perkAndPreqs _ NULL = []
perkAndPreqs ps p = [p] ++ perkAndPreqs ps preq
where
PerkImpl (_, _, _, _, _, preqstring, _) = p
preq = perkIdentifier preqstring ps
My guess is that when you call calctvd by hand, the p parameter you pass is not also the first element of the ps parameter. But when calctvd is called from updatetvd, p = head ps.
I cannot be sure, because you've shown us neither failing test cases nor the definition of perkAndPreqs (if points is being miscalculated as 1, the clue as to why is likely to be in perkAndPreqs).

Resources