- Haskell-Cafe - Haskell.org

Typeclass Constraint Causing Typechecker to Fail
by James M 20 Apr '16

20 Apr '16

Below I have a contrived example. Please do not take this to be real world code. f :: (Show a) => Int -> (Int -> a) -> Int -> IO a f i g x = do print i return $ g (x + i) foo :: Bool -> IO (Either [Int] [String]) foo b = do let helper = f 2 if b then Left <$> sequence (fmap (helper negate) [0,1]) else Right <$> sequence (fmap (helper show) [0,1]) The above will fail stating Example.hs:14:35: Couldn't match type ‘Int’ with ‘[Char]’ Expected type: Int -> IO String Actual type: Int -> IO Int In the first argument of ‘fmap’, namely ‘(helper show)’ In the first argument of ‘sequence’, namely ‘(fmap (helper show) [0, 1])’ Example.hs:14:42: Couldn't match type ‘[Char]’ with ‘Int’ Expected type: Int -> Int Actual type: Int -> String In the first argument of ‘helper’, namely ‘show’ In the first argument of ‘fmap’, namely ‘(helper show)’ However, if I simply change f's type signature to not have the typeclass constraint, the type checker is happy: f :: Int -> (Int -> a) -> Int -> IO a Another possibility to remove the problem is to remove the let statement and instead put the entire expression in. foo :: Bool -> IO (Either [Int] [String]) foo b = do if b then Left <$> sequence (fmap (f 2 negate) [0,1]) else Right <$> sequence (fmap (f 2 show) [0,1]) This seems to be a bug in the typechecker, and maybe it is a well known issue. Can someone please confirm that this is a bug and whether or not it is known? James

3 2

Re: [Haskell-cafe] Is it possible to make lazy combinators for IO?
by David Feuer 20 Apr '16

20 Apr '16

lazyMap :: (a -> b) -> IO a -> IO b, hypothetically. Let me take a step back. There are two ways I know of to use the result of an IO action. The most common way, by far, is to use >>= to send it on to the next computation. The other notable way is to use fixIO. No part of the result of an IO action becomes available until that action "completes" (in the shady case of lazy IO, this may be immediate, but I'm ignoring lazy IO for this discussion). This causes the well-known inefficiency of mapM in IO: individual results cannot be consed until the entire computation is complete. It seems to cause much more painful effects for fixIO--lazy programming techniques may simply be unavailable. For example, it's possible for a pure computation using a queue in a single-threaded fashion to represent that queue as a list, tying the knot to pass the list of all enqueued elements to the beginning. If an IO computation wants to use a queue, this technique does not seem to be available. The knot can be tied with fixIO, but conses are delayed until it's too late--attempting to dequeue an element will block forever. I'm wondering if there's some way to make this sort of thing work, either with plain Haskell IO or some thin layer built on top. On Apr 18, 2016 5:12 PM, "David Turner" <dct25-561bs(a)mythic-beasts.com> wrote: > Sorry, you've lost me. I suspect you're trying to give a minimal example > of the problem you're having, but you've stripped away too much context. > What are lazyMap and f? At least, what are their types? > On 18 Apr 2016 22:03, "David Feuer" <david.feuer(a)gmail.com> wrote: > >> Consider the implementation of `second` for pairs: >> >> second f ~(a,b) = (a, f b) >> >> Now >> >> fix $ second (3 :) >> >> Will be (undefined, [3,3,....]) >> >> Translating this to IO, I'd want >> >> lazyMap f undefined >> >> to produce as much as possible of the result, although it cannot produce >> the final State# RealWorld token. >> On Apr 18, 2016 4:47 PM, "David Turner" <dct25-561bs(a)mythic-beasts.com> >> wrote: >> >>> You can't know that the final result of the computation (x `seq` >>> (3:...)) will begin with 3, because sometimes it doesn't! More >>> specifically, it diverges (without yielding the 3) if x diverges. >>> >>> I don't think this is anything special about mfix: (let x = x `seq` >>> 3:... in x) also diverges for the same reason. >>> >>> Hope that helps, >>> >>> David >>> On 18 Apr 2016 21:19, "David Feuer" <david.feuer(a)gmail.com> wrote: >>> >>>> If >>>> >>>> f :: a -> IO a >>>> >>>> for some a, and I want to use >>>> >>>> mfix f >>>> >>>> then f must not inspect its argument in any way, or the computation >>>> will get stuck. In some cases, this seems a bit harsh. For example, >>>> >>>> mfix (\x -> fmap (3 :) (x `seq` readLn)) >>>> >>>> looks perfectly reasonable. There is no need to inspect the return [] >>>> action to know that the final result of the computation will begin >>>> with 3:. Is there a lazy IO mapping function somewhere that can work >>>> such magic? >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>

2 2

Existential quantification of config data types
by Charlie Durham 19 Apr '16

19 Apr '16

Hi, I'm running into a weird problem i've never had before. I want to define a datatype like: data Network = forall a. Layer a => Network [a] for which I have things that implement Layer, like data TypicalLayer = ... instance Layer TypicalLayer where ... with this, I want to be able to load a Network from a config file where Network can consist of different data types all implementing Layer. Is there a nice way to do this without making a data type that combines all of my layer types, something like: data LayerType = TypicalLayerType TypicalLayer | AnotherLayerType AnotherLayer ... deriving (Show,Read) Thanks for the help! Charlie Durham

2 3

Re: [Haskell-cafe] Sending email
by David Escobar 19 Apr '16

19 Apr '16

No explicit mention is made anywhere in the documentation about TLS or even SSL, so perhaps not? Some libraries I've come across specifically mention that they don't support TLS or SSL. Being relatively new to this part of Haskell, what is the most standard library the community uses for email that supports modern protocols such as those used by GMail? Thanks. On Mon, Apr 18, 2016 at 2:49 PM, Alex Feldman-Crough <alex(a)fldcr.com> wrote: > Does the library support TLS? Does it have to be configured differently? > It sounds like a negotiation error to me. > On Mon, Apr 18, 2016 at 2:43 PM David Escobar <davidescobar1976(a)gmail.com> > wrote: > >> Hi everyone, >> I'm trying to use the *Network.Mail.SMTP* library to send email: >> >> *{-# LANGUAGE OverloadedStrings #-}* >> >> *module Main where* >> >> *import Control.Exception* >> >> *import qualified Data.Text as T* >> *import qualified Data.Text.Lazy as LT* >> *import Network.Mail.SMTP* >> >> *main :: IO ()* >> *main = do* >> * sendEmail (“Person sender”, “sender@somewhere.com >> <sender(a)somewhere.com>”)* >> * [(“Person recipient“, “recipient@somewhere.com >> <recipient(a)somewhere.com>”)]* >> * "Test email"* >> * "Some message goes here."* >> >> >> *sendEmail :: (T.Text, T.Text) -> [(T.Text, T.Text)] -> T.Text -> T.Text >> -> IO ()* >> *sendEmail (fromName, fromEmail) toAddresses subject' body' = do* >> * let toNameAddrs = map (\(toName, toEmail) -> Address (Just toName) >> toEmail) toAddresses* >> * msg = simpleMail (Address (Just fromName) fromEmail)* >> * toNameAddrs* >> * []* >> * []* >> * subject'* >> * [ plainTextPart $ LT.fromStrict body' ]* >> * result <- try $ sendMailWithLogin' "smtp.gmail.com >> <http://smtp.gmail.com>"* >> * 465 -- SSL port* >> * “sender_login”* >> * “sender_password”* >> * msg :: IO (Either SomeException ())* >> * case result of* >> * Left e -> putStrLn $ "Exception caught: " ++ (displayException e)* >> * Right _ -> putStrLn "Sent email successfully."* >> >> >> The program compiles, but when I run it, I get: >> >> *Exception caught: <socket: 49>: Data.ByteString.hGetLine: end of file* >> >> I tried using the TLS port of 587, but then I just get an authentication >> failure. Am I using the wrong library or is it just the wrong >> configuration. Thanks. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -- > Alex Feldman Crough > 602 573-9588

4 7

diffs on HaskellWiki
by Patrick Pelletier 19 Apr '16

19 Apr '16

I've noticed that when viewing changes on HaskellWiki, the diffs are missing. We had a similar problem on the OpenSSL wiki (which, like HaskellWiki, is based on MediaWiki), and the sysadmin said he fixed the problem by switching from the external diff engine to the internal diff engine. Is there someone who could look into this and possibly make that change to the wiki's configuration? I looked around the HaskellWiki and couldn't find any mention of how to contact a maintainer. Thanks, --Patrick

1 0

Is it possible to make lazy combinators for IO?
by David Feuer 19 Apr '16

19 Apr '16

If f :: a -> IO a for some a, and I want to use mfix f then f must not inspect its argument in any way, or the computation will get stuck. In some cases, this seems a bit harsh. For example, mfix (\x -> fmap (3 :) (x `seq` readLn)) looks perfectly reasonable. There is no need to inspect the return [] action to know that the final result of the computation will begin with 3:. Is there a lazy IO mapping function somewhere that can work such magic?

2 4

[ANNOUNCE] GHC 8.0.1 release candidate 3 available
by Ben Gamari 19 Apr '16

19 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of third release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc3/ This is the third of what will be four candidates leading up to the 8.0.1 release. As there are a number of known issues with this candidate, we expect to produce the fourth and final release candidate shortly. While we considered not releasing this candidate at all and instead skipping to rc4, we decided that it would be helpful to make it available despite its issues to increase the likelihood of catching any remaining bugs. That being said, this candidate lacks the range of binary distributions which we usually offer, * We are unable to release Windows bindists due to a compatibility issue which we didn't catch until after preparing the source distribution. * Binaries targeting Redhat distributions are currently not available Regardless, users for whom a distribution is available are encouraged to try this candidate as it fixes dozens of issues present in release candidate two. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). Unfortunately, this candidate does not notice this brokenness and odd behavior can result. OS X users running XCode 7.3 are encouraged to open a ticket with Apple and build GHC with the `--with-nm=nm-classic` configure option until a fix is available. As mentioned earlier, there are a number of known issues with this candidate which will be addressed in release candidate four. These issues include, * A number of typechecker bugs (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell lacks the ability to produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has inadequate version checks for libdw (#11820) * Typeable and hs-boot files interact poorly (#11824) * The build system doesn't check for the broken Apple `nm` utility, leading to unpredictable results (#11823, #11744) We hope to have release candidate four available by the middle of next week. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers, - Ben

1 0

Pretty-printing haskell source code - could the line breaking be improved?
by David Fox 19 Apr '16

19 Apr '16

When I pretty print a certain deleration (with default width) I get this: upeekRow _unv (_xconc@(ImageSize {})) = Node (upeekCons idPath Nothing) (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Dimension) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Dimension]))) [UPath_ImageSize_dim] ++ (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Double) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Double]))) [UPath_ImageSize_size] ++ (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Units) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Units]))) [UPath_ImageSize_units] ++ []))) However, what I would like to see is something closer to this: upeekRow _unv (_xconc@(ImageSize {})) = Node (upeekCons idPath Nothing) (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Dimension) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Dimension]))) [UPath_ImageSize_dim] ++ (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Double) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Double]))) [UPath_ImageSize_size] ++ (concatMap (\f -> forestMap (liftPeek f) (map (\x' -> Node (upeekCons idPath (Just (u x' :: Univ)) :: UPeek Univ Units) []) (toListOf (toLens (f idPath) . ulens' (Proxy :: Proxy Univ)) _xconc :: [Units]))) [UPath_ImageSize_units] ++ []))) So I guess what I'm seeing is that as it is traversing the syntax tree when it finds it is too far to the right it just inserts a line break - but since it is so far down the tree it only buys it a few spaces, whereas if it had backtracked a few levels up the tree the new position would be much further to the left. Could anyone point me towards the code that implements this decision making? I'm pretty sure it is in the display function Text.PrettyPrint.Annotated.HughesPJ, but the code there doesn't make much sense to me. Any thoughts would be appreciated. David Fox

1 0

Re: [Haskell-cafe] Haskell on OpenWRT
by Patrick Pelletier 18 Apr '16

18 Apr '16

On 4/17/16 4:13 PM, Henk-Jan van Tuyl wrote: > Could you create a HaskellWiki page (called OpenWRT) describing how to > do this? Or send the text to me, so that I can put it in a HaskellWiki > page. Sure. I had written some detailed text about my cross-compilation adventure for my blog, so I went ahead and used that as the starting point for the wiki page: https://wiki.haskell.org/OpenWRT It's written in a much more narrative, first-person style than is really appropriate for a wiki, so of course please feel free to edit it to make it more appropriate for that context. I also haven't linked that page from anywhere else on the wiki yet, so feel free to do that, too. --Patrick

1 0

Building shared library to be called from C
by Jack Hill 18 Apr '16

18 Apr '16

Hi, I'm attempting to build a shared library that can be called from C. My end goal is to build a PAM module, but for now I'm working with toy programs so that I can get a feel for building how to build the library. The Haskell part looks like this (in a file called hfact.hs) module Hfact where import Foreign import Foreign.C.Types foreign export ccall fact_hs :: CInt -> CInt fact :: Int -> Int fact x = product [1..x] fact_hs :: CInt -> CInt fact_hs = fromIntegral . fact . fromIntegral I can compile this into a so (I think successfully) with "ghc --make -shared -dynamic -fPIC -o libhfact.so hfact.hs". Now I would like to be able to call this from C. I have a C program (in a file called main.c) as follows: #include <stdio.h> #include "HsFFI.h" #include "hfact_stub.h" int main(int argc, char *argv[]) { int user, answer; scanf("%d", &user); hs_init(&argc, &argv); answer = fact_hs(user); hs_exit(); printf("Result: %d\n", answer); return 0; } Unfortunately, I'm at a loss for how to build and link this against my so. If I try "gcc main.c -lhfact", I get many undefined symbol errors like: /nfshomes/j/jackhill/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM-ghc7.10.3.so: undefined reference to `__hscore_get_saved_termios' If I try "ghc maint.c -lhfact" I get: /tmp/ghc19146_0/ghc_4.o: In function `main': ghc_3.c:(.text+0x0): multiple definition of `main' maint.o:maint.c:(.text+0x0): first defined here /tmp/ghc19146_0/ghc_4.o: In function `main': ghc_3.c:(.text+0x61): undefined reference to `ZCMain_main_closure' collect2: error: ld returned 1 exit status How should I be calling Haskell from C? Best, Jack

3 2