April 2016 - Haskell-Cafe

[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

is monomorphism restriction necessary?
by Alexey Muranov 17 Apr '16

17 Apr '16

Sorry for the question that probably is already answered somewhere, but i do not get it from the basic documentation i have looked at so far. Is monomorphism restriction really necessary, or is it just a convenience? In the example from A History of Haskell genericLength :: Num a => [b] -> a f xs = (len, len) where len = genericLength xs can't the monomorphism restriction be replaced with just adding the signature f :: Num a => [b] -> (a, a) ? If yes, are there other cases where there is no way to get the desired behavior without enabling the monomorphism restriction? Alexey.

2 4

[ANN] sarsi 0.0.2.0 - A universal quickfix toolkit and his protocol (nvim/vim)
by Alois Cochard 17 Apr '16

17 Apr '16

Hello Café, Here is a new tool which should basically improve the "quick fixing" experience in Haskell with vim/neovim. The aim is not to replace any of the great features provided by integrating the type checker in the editor, but to complement them with a different approach. I explain the motivation there: http://aloiscochard.blogspot.ch/2016/04/quickfix-all-things-with-sarsi.html If you feel like this might be a tool for you, you can jump straight to the README to find the install and usage instructions: https://github.com/aloiscochard/sarsi I did test it extensively with stack, let me know if you have issues using an other tool (I do only pipe stderr which is fine for stack, I suspect this might not be the case for others). Thanks -- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

3 5

Haskell on OpenWRT
by Patrick Pelletier 16 Apr '16

16 Apr '16

Has anyone had any success running Haskell programs on OpenWRT? Specifically, I'm running OpenWRT on x86_64, so processor architecture shouldn't be an issue. However, by default OpenWRT uses musl as its C library, so binaries from a "normal" Linux system wouldn't be compatible with OpenWRT. I attempted to get around this problem by building an OpenWRT image with glibc as the C library. In theory, that ought to solve the problem. In practice, my program (a simple hello-world type program, which runs fine on Ubuntu) hung, printing nothing, using nearly all of one core, and was unkillable by any signal other than SIGKILL. If left alone to run, it eventually used all available memory and then died. I took a look at ldd, to see if there were any clues there. On my Ubuntu 12.04 machine, where I compiled the program (using ghc 7.4.1), I get: ppelletier@patrick64:~/programming/haskell$ ldd contact linux-vdso.so.1 => (0x00007fff36f50000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f8d49cf8000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f8d49af0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8d497f3000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8d495eb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8d493e7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d49028000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8d48e0b000) /lib64/ld-linux-x86-64.so.2 (0x00007f8d49f8d000) On my OpenWRT (trunk) box, I get: root@OpenWrt:~# ldd /tmp/contact linux-vdso.so.1 (0x00007ffd2afcc000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f27a057a000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f27a0373000) libm.so.6 => /lib/libm.so.6 (0x00007f27a0080000) librt.so.1 => /lib/librt.so.1 (0x00007f279fe79000) libdl.so.2 => /lib/libdl.so.2 (0x00007f279fc76000) libc.so.6 => /lib/libc.so.6 (0x00007f279f906000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f279f6f4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f279f4d9000) /lib64/ld-linux-x86-64.so.2 (0x00007f27a07dc000) This is almost the same, except it has "libgcc_s.so.1", while on the Ubuntu box it does not. I'd welcome any ideas on how to solve (or at least diagnose) this problem. I'd also be interested in any thoughts on the broader question of running Haskell programs on OpenWRT. Thanks, --Patrick

3 8

Re: [Haskell-cafe] Hugs
by Johannes Waldmann 15 Apr '16

15 Apr '16

> the learning process for a student rarely > involves consuming a precise, coherent definition, But it should! I do make a point of embedding references to actual standards in my teaching, mostly in exercises like "what paragraph of the (e.g., Java) language spec. says that the following program is illegal". The intention is: students should a) get used to reading (semi-)formal specifications b) see that concepts from "theory" (lecture, papers) appear verbatim in actual "industrial" specs c) get scared of using software/language that has no specification > .. the nature of functional programming supported by a review of the > theory upon which it is founded: at the very least, the lambda > calculus, preferably along with some basic ideas from type theory. That. And I do start my FP teaching with term rewriting, as a model of first-order programming. (gives you terms as a model of data, and rewrite rule application as a model of pattern matching) - J.W.

1 0

Re: [Haskell-cafe] Hugs
by Doug McIlroy 15 Apr '16

15 Apr '16

> I really do think that pointing students to an unmaintained language > implementation (regardless of the pedagogical reasons) has negative > consequences for the functional programming community as a whole. If it works, maintenance doesn't matter. So, I assume the real concern is that Hugs isn't evolving. To put it in the worst light, this may be read as a complaint that Hugs doesn't keep up with some party line. I would hate to think that the "community as a whole" is that conformist. The disdain for "pedagogical reasons" brushes aside an implicit wakeup call to the community. Hugs is attractive because it is well described and bounded, whereas Haskell realized in GHC lacks a coherent description and presents a myriad of often inscrutable faces. To the extent that the community is defined by such an artifact, it has turned away from educators, not vice versa. Learning how to wrangle a marvelous, but cantankerous, beast should not be confounded with initiation to the insights of functional programming. Doug McIlroy

4 3

Re: [Haskell-cafe] Hugs
by Johannes Waldmann 15 Apr '16

15 Apr '16

> https://twitter.com/headinthebox/status/652834731806052352 This mentions and :: Foldable t => t Bool -> Bool as an example of "abstract nonsense". Well, I will run into teaching this soon myself, though not to freshmen - my students had some Java before but not Haskell. With regards to the type of "and", I will first have them write "data List a = ..." and a concrete "and :: List Bool -> Bool" from scratch. Later, to explain the type of "the true and" I will claim that the corresponding Java method would have type "static Boolean and (Iterable<Boolean> xs)" where Iterable<> is an interface (that the students should know). That's not too bad: xs.iterator() corresponds to toList xs (a lazy stream). "toList" would even be a complete definition for the Foldable instance? (since foldr f z = foldr f z . toList ) So perhaps "Foldable \approx Iterable \approx Enumerable" is a useful guideline. (Yes, there is a difference between a one-argument type class and an interface. But they have some common use cases.) - J.W.

4 3