October 2015 - Haskell-Cafe

Why does disambiguation in RebindableSyntax sometimes requires type signatures?
by Jan Bracker 02 Nov '15

02 Nov '15

Hello, I am currently playing around with RebindableSyntax and having several bind/return/sequence functions in scope at the same time. I thought that it would be enough to just pick the right one to use in each do-block by using a "where" or a "let". Surprisingly, I get some type related issues I can only fix by adding in some type signatures, but I don't understand why these signatures are actually necessary. Here is my example program: {-# LANGUAGE RebindableSyntax #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} import Prelude import qualified Prelude as P import qualified Control.Effect as E import Control.Effect.State ifThenElse :: Bool -> a -> a -> a ifThenElse True t e = t ifThenElse False t e = e main :: IO () main = do return () where return = P.return data Tree = Leaf Int | Branch Tree Tree process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree [Int]) process (Leaf i) = do flatten <- get (Var :: (Var "flatten")) if flatten then return $ Right [i] else return $ Left $ Leaf i where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail process (Branch tl tr) = do eitherL <- process tl eitherR <- process tr case (eitherL, eitherR) of (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail The program uses the "effect-monad" package in version 0.6.1. 1) The type signatures in the "where" following each do-block of the "process" function are required. If I remove the type signature of the sequence functions I get a type error of the following nature: examples/effect/Test.hs:33:16: Could not deduce (E.Inv m0 f0 g0) arising from a use of ‘E.>>’ Relevant bindings include (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b (bound at examples/effect/Test.hs:33:9) In the expression: (E.>>) In an equation for ‘>>’: (>>) = (E.>>) In an equation for ‘process’: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail examples/effect/Test.hs:33:16: No instance for (E.Effect m0) arising from a use of ‘E.>>’ In the expression: (E.>>) In an equation for ‘>>’: (>>) = (E.>>) In an equation for ‘process’: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail Which I interpret as the inability to infer the "E.Effect" and "E.Inv" constraints that are implied by the use of "E.>>". But why can't those constraints be inferred correctly? Shouldn't a definition like "(>>) = (E.>>)" just propagate the type signature and specialize it as needed? 2) If I remove the type signature for the bind operation, I get the following type error: examples/effect/Test.hs:38:3: Couldn't match type ‘'["flatten" :-> (Bool :! 'R)]’ with ‘'[]’ Expected type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State '[] (Either Tree [Int]) Actual type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State (E.Plus State '["flatten" :-> (Bool :! 'R)] '[]) (Either Tree [Int]) In a stmt of a 'do' block: eitherR <- process tr In the expression: do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } In an equation for ‘process’: process (Branch tl tr) = do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } where (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return Which tells me that GHC is expecting the wrong type, but inferring the correct type. Again I don't see why this wrong type is expected and the right type is ignored. In either case, why does adding or removing the type signature for the local definitions make a difference at all? I suspect the issue has to do with the language extensions I enabled or the type-level computations that are done by the "effect-monad" package, but I cannot find a satisfying answer. Does anybody have a good explanation? I am working with GHC 7.10.2. Best, Jan

3 5

testing for exceptions
by Roelof Wobben 02 Nov '15

02 Nov '15

Hello, I have made this exercise which can be found at the Craft of Functional Programming book. -- exercise 32 -- Suppose we have to raise 2 to the power n. If n is even, 2*m say, then -- 2n = 22*m = (2m)2 -- If n is odd, 2*m+l say, then -- 2n = 22*m+l = (2n)2*2 -- Give a recursive function to compute 2n which uses these insights. f2 :: Integer -> Integer f2 n | n < 0 = error "This will only run for positive numbers" | n == 0 = 1 | even n = f2 ( n `div` 2) ^ 2 | odd n = (f2 ( n `div` 2) ^ 2) * 2 Now I have to make Hunit tests for it, But is there a way I can test if the error message is shown when a negative number is being used ? Roelof

8 18

what do I have to do exactlry with this exercises
by Roelof Wobben 02 Nov '15

02 Nov '15

Hello, Im self studing Haskell with the Craft o ffunctional programmimg of Hutton. Now I see two exercises that I do not understand what is really the purpose here. The two exercises are : 4.21 Given a function f of type Integer -> Integer give a recursive definition of a function of type Integer -> Integer which on input n returns the maximum of the values f 0, f 1, ..., f n. You might find the max function defined in Section 3.4 useful. To test this function, add to your script a definition of some values of f thus: f 0 = 0 f 1 = 44 f 2 = 17 f _ = 0 and so on; then test your function at various values. 4.22 Given a function f of type Integer -> Integer give a recursive definition of a function of type Integer -> Bool which on input n returns True if one or more of the values f 0, f 1, ..., f n is zero and False otherwise.

3 10

Find a point inside (x,y,z) -> Bool
by martin 02 Nov '15

02 Nov '15

Hello all, I hope this is not a too silly question. It goes like this: Suppose I have a shape defined as (x,y,z) -> Bool how can I find a Point inside this shape? Obviously I could iterate through all possible x,y and z, but this appears very expensive. There may be no point at all at x=0. With brute force iteration I would have no clue that the False I am receiving with (0,1,1) is caused by x=0 and I may nedlessly try all combinations of y and z without ever receiving a True. Are there any alternative ways of finding points inside a shape?

11 16

ANN: hledger-0.27, with more console power
by Simon Michael 31 Oct '15

31 Oct '15

I'm pleased to announce hledger 0.27! What is it ? hledger is a cross-platform program for tracking money, time, or any other commodity, using double-entry accounting and a simple, editable file format. It can also read CSV or timelog files, and export CSV. It provides command-line, curses and web interfaces, and aims to be a reliable, practical tool for daily use. It is inspired by and largely compatible with ledger(1). What's new ? This release introduces hledger-ui, a new curses-style interface that I'm quite pleased with (not yet available on Windows). Built on vty and the new brick library, it lets you review account balances and transactions with fewer keystrokes and less effort. Ledger users with compatible journal files may also find this useful. hledger can now report current value based on market prices (hurrah); wide characters are displayed properly; regular expression account aliases are fast; and unix man pages are provided. You can see all changes and bugfixes at http://hledger.org/release-notes#hledger-0.27 . Release contributors: Simon Michael, Carlos Lopez-Camey. How to get it ? hledger can be installed with cabal or stack - see http://hledger.org/download for guidance. If you'd like to contribute Windows or Mac binaries, please get in touch. Happy Hallowe'en! -Simon

1 0

Re: [Haskell-cafe] Determining the length of a Foldable Applicative.
by David Banas 31 Oct '15

31 Oct '15

Thanks to all, whom responded to this! With your help, I found my way to this, which seems to work correctly: app_len :: (Foldable f) => f a -> Int app_len = foldl' (flip ((+) . const 1)) 0 -db On Oct 30, 2015, at 2:47 PM, David Kraeutmann <kane(a)kane.cx> wrote: > Your types don't match here, but you have the right idea. > > 'sum' won't be enough. Take a look at the definition of sum: > >> sum :: (Foldable t, Num a) => t a -> a >> sum = getSum . foldMap Sum > > That won't work, since that requires '(Num a)'. > > We just want to count 1 up whenever we map an element. > Try doing something with const and Data.Monoid.Sum. > > > On 10/30/2015 9:03 PM, David Banas wrote: >> Hi all, >> >> I thought I had a simple way to determine the “length" (i.e. - number of elements in) of a Foldable Applicative container: >> >> import Prelude hiding (sum) >> import Data.Foldable (Foldable(..), sum) >> import Control.Applicative >> >> -- Calculate the "length" (i.e. - number of elements in) an Applicative container. >> app_len :: (Applicative f, Foldable f) => f a -> Int >> app_len = sum $ pure 1 >> >> but I didn’t: >> >> app_len_test.hs:9:11: >> Could not deduce (Foldable t0) arising from a use of ‘sum’ >> from the context (Applicative f, Foldable f) >> bound by the type signature for >> app_len :: (Applicative f, Foldable f) => f a -> Int >> at app_len_test.hs:8:12-52 >> The type variable ‘t0’ is ambiguous >> Note: there are several potential instances: >> instance Foldable ((,) a) -- Defined in ‘Data.Foldable’ >> instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) >> -- Defined in ‘Data.Foldable’ >> instance Foldable (Const m) -- Defined in ‘Data.Foldable’ >> ...plus four others >> In the expression: sum >> In the expression: sum $ pure 1 >> In an equation for ‘app_len’: app_len = sum $ pure 1 >> >> app_len_test.hs:9:17: >> Could not deduce (Applicative t0) arising from a use of ‘pure’ >> from the context (Applicative f, Foldable f) >> bound by the type signature for >> app_len :: (Applicative f, Foldable f) => f a -> Int >> at app_len_test.hs:8:12-52 >> The type variable ‘t0’ is ambiguous >> Note: there are several potential instances: >> instance Data.Monoid.Monoid a => Applicative ((,) a) >> -- Defined in ‘Control.Applicative’ >> instance Applicative ((->) a) -- Defined in ‘Control.Applicative’ >> instance Control.Arrow.Arrow a => >> Applicative (Control.Arrow.ArrowMonad a) >> -- Defined in ‘Control.Applicative’ >> ...plus 14 others >> In the second argument of ‘($)’, namely ‘pure 1’ >> In the expression: sum $ pure 1 >> In an equation for ‘app_len’: app_len = sum $ pure 1 >> >> Can anyone help me understand what I’m missing? >> >> Thanks, and have a great weekend, >> -db >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >

1 0

Determining the length of a Foldable Applicative.
by David Banas 30 Oct '15

30 Oct '15

Hi all, I thought I had a simple way to determine the “length" (i.e. - number of elements in) of a Foldable Applicative container: import Prelude hiding (sum) import Data.Foldable (Foldable(..), sum) import Control.Applicative -- Calculate the "length" (i.e. - number of elements in) an Applicative container. app_len :: (Applicative f, Foldable f) => f a -> Int app_len = sum $ pure 1 but I didn’t: app_len_test.hs:9:11: Could not deduce (Foldable t0) arising from a use of ‘sum’ from the context (Applicative f, Foldable f) bound by the type signature for app_len :: (Applicative f, Foldable f) => f a -> Int at app_len_test.hs:8:12-52 The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Foldable ((,) a) -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ instance Foldable (Const m) -- Defined in ‘Data.Foldable’ ...plus four others In the expression: sum In the expression: sum $ pure 1 In an equation for ‘app_len’: app_len = sum $ pure 1 app_len_test.hs:9:17: Could not deduce (Applicative t0) arising from a use of ‘pure’ from the context (Applicative f, Foldable f) bound by the type signature for app_len :: (Applicative f, Foldable f) => f a -> Int at app_len_test.hs:8:12-52 The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Data.Monoid.Monoid a => Applicative ((,) a) -- Defined in ‘Control.Applicative’ instance Applicative ((->) a) -- Defined in ‘Control.Applicative’ instance Control.Arrow.Arrow a => Applicative (Control.Arrow.ArrowMonad a) -- Defined in ‘Control.Applicative’ ...plus 14 others In the second argument of ‘($)’, namely ‘pure 1’ In the expression: sum $ pure 1 In an equation for ‘app_len’: app_len = sum $ pure 1 Can anyone help me understand what I’m missing? Thanks, and have a great weekend, -db

4 3

MonadFix wiki confusion
by Samuel Rødal 30 Oct '15

30 Oct '15

Hello, the MonadFix wiki at https://wiki.haskell.org/MonadFix has a statement that I feel is a bit misleading. In section "2.2 Lazy algorithm interleaved with effects", it claims that making the BTree data structure strict doesn't cause endless recursion. Well, that's true, but that's just because rep_x_sum returns a tuple containing the BTree and the summed values of the current subtree, and the tuple is lazily constructed - postponing the construction of the tree value. So highlighting the fact that the function still works when the BTree structure is made strict is kind of a red herring. Maybe the confusion could be avoided by removing the part about making BTree strict, or adding a note about the tuple still ensuring lazy construction? -- Samuel

3 4

Re: [Haskell-cafe] Find a point inside (x,y,z) -> Bool
by Olaf Klinke 30 Oct '15

30 Oct '15

Martin, this may be impractical performance-wise, but Haskell offers magic data structures for searching. Have a look at Martin Escardo's blog post [1] on infinite search in finite time. There is a package on Hackage [2] implementing it. The `shapes` you get are compact, non-empty subsets of types. If you have a shape shape :: Data.Searchable.Set a then Data.Searchable.search (const True) shape will return some element of your shape. As far as I know nobody has ever used this data structure for solid geometry. You'd need to combine it with some implementation of exact reals [*] to have geometry in a product of closed intervals. A downside is that general intersections don't exist, since the shapes must be non-empty. But since images of searchable sets are searchable, you could define complicated shapes by starting with a simple one and distort it with a function. If your type of space is discrete, then the search function might resort to brute force enumeration if the shape was defined that way. -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-fi… [2] http://hackage.haskell.org/package/infinite-search [*] As far as I am aware there is no appropriate package on Hackage, but Haskell implementations exist in several theses.

1 0

Re: [Haskell-cafe] haskell-ide repository name
by Alan & Kim Zimmerman 30 Oct '15

30 Oct '15

This post generated some discussion on the mailing list(s) [1],[2] and on reddit [3]. The straw poll [4] garnered (as of time of writing this mail) 138 votes, broken down as ghc-ide-engine 56 votes 41% ghc-ide-service 43 votes 31% haskides 19 votes 14% ghc-ide-daemon 16 votes 12% something else 4 votes 3% So it seems -ide-engine is the favourite In a bait-and-switch operation, I think it makes sense to keep the current "haskell-ide" prefix, and so rename it to haskell-ide-engine This has the advantages of a) The prefix is the same, so continuity is slightly better b) It does not mentally shut out any tooling constructed using other compilers/techniques, such as haskell-src-exts If anyone feels strongly that this is wrong, please let me know. Regards Alan [1] https://mail.haskell.org/pipermail/haskell-cafe/2015-October/121965.html [2] https://groups.google.com/forum/#!topic/haskell-ide/hI3MzXbwqTo [3] https://www.reddit.com/r/haskell/comments/3qh19i/rename_haskellide_project/ [4] http://strawpoll.me/5842105/r On Mon, Oct 26, 2015 at 11:06 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > At the moment the repository/project is called haskell-ide > > This leads to the impression that it is an IDE. > > It is actually a backend/server to provide services for an IDE > > We are considering changing the name. > > The options are > > haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine > > Please cast your vote at http://strawpoll.me/5842105 > > Thanks > Alan >

1 1