November 2014 - Glasgow-haskell-users

Discovery of source dependencies without --make
by Lars Hupel 13 Dec '15

13 Dec '15

(cross-posted from [haskell-cafe]) Hi, I've got a problem in our – admittedly complex – build process. We're running an automated grading system for student-submitted homework exercises. The compilation proceeds in stages: 1) Compile a library file, marked as trustworthy 2) Compile student submissions using Safe Haskell, able to access a whitelisted set of packages and the previously compiled library files 3) Compile the test suite 4) Link everything together into an executable The invocation is similar to this: ghc -c -outputdir "$OUT" -XTrustworthy Library.hs ghc -c -outputdir "$OUT" -i"$OUT" -XSafe "$SUBMISSION" ghc -c -outputdir "$OUT" -i"$OUT" Test_Suite.hs ghc -outputdir "$OUT" -i"$OUT" -o "$OUT/runner" The second stage works well under the assumption that there's just one single submitted file. If there's more than one, I need to specify them in topological order wrt their module dependencies. Consider two simple modules: A.hs > module A where > > import B > import Library B.hs > module B where Invoking GHC with "A.hs" "B.hs" will fail: A.hs:3:1: Failed to load interface for ‘B’ My naive attempt at solving that problem was to just insert "--make" into the compiler flags. No luck, because according to [1, §4.7.3], "--make" will only look at source files and will ignore the "Library.hi" file from the previous compilation stage. If I give the path to "Library.hs" as well, GHC insists on recompiling it with changed flags ("-XSafe" instead of "-XTrustworthy"). Reading a bit further, I discovered the '-M' flag, however, not only does it output Makefile-formatted output, it also ignores .hi files. Is there any way to get the dependency discovery of '--make' without the rest? I know I could probably make it work if I made a package out of the first build stage, but I really want to avoid that in order to not increase the build complexity even further. Cheers Lars [1] <https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/separate-com…>

8 15

Thread behavior in 7.8.3
by Michael Jones 21 Jan '15

21 Jan '15

I have a general question about thread behavior in 7.8.3 vs 7.6.X I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination. When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so. When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4. The program is compiled -O2 with profiling. The -N2/4 version uses more memory, but in both cases with 7.8 and with 7.6 there is no space leak. I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running. One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler. What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help? I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get. Any hints appreciated. Mike

9 29

Re: GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 04 Jan '15

04 Jan '15

I wrote: >> This thread makes it clear what a mess >> we have inherited from the days when GHC was primarily a >> research compiler. Let's face it - GHC is now also a serious >> production compiler, and this urgently needs to be cleaned up. hvr wrote: > Are you referring to the GMP dependency or something else? > ...I'm not sure what can be done differently here. Agreed. No, not any one of those many little details. I mean the general extreme difficulty of getting almost any version of GHC working on almost any platform, unless the two were released within a fairly short time of each other. Well, that is, not counting your wonderful ppa for Ubuntu. That is fantastic - but the dire need for it is evidence for the severity of the problem. How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources. If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version. I realize that this might be disruptive to GHC devs, because as a compiler with a research heritage, GHC experiments with its own new features on its own source code. But as a compiler that is used commercially, some general kind of backward portability is critically important. The other direction is equally problematic. Although GHC does support bootstrapping itself from a few previous releases, porting GHC to a new platform has become harder and harder as GHC becomes more complex. I think this could become a threat to the viability of GHC - technology is always changing. As a commercial developer, I am always plagued by nagging worry about GHC portability, forward and backward. Will we always be able in the future to support code we release, or will it die someday because there will no longer exist a GHC able to compile it? Will our whole technology die someday just because we can't get GHC working on a platform we need to support? Thanks, Yitz

2 3

Proving properties of type-level natural numbers obtained from user input
by Bas van Dijk 19 Dec '14

19 Dec '14

Hi, I have another type-level programming related question: > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE KindSignatures #-} > > import GHC.TypeLits Say I have a Proxy p of some type-level natural number: > p :: forall (n :: Nat). Proxy n > p = Proxy Imagine I get p from user input like this: > main :: IO () > main = do > [arg] <- getArgs > let n = read arg :: Integer > > case someNatVal n of > Nothing -> error "Input is not a natural number!" > Just (SomeNat (p :: Proxy n)) -> ... I also have a function f which takes a proxy of a natural number but it has the additional constraint that the number should be lesser than or equal to 255: > f :: forall (n :: Nat). (n <= 255) => proxy n -> () > f _ = () How do I apply f to p? Obviously, applying it directly gives the type error: > f p <interactive>:179:1: Couldn't match expected type ‘'True’ with actual type ‘n0 <=? 255’ The type variable ‘n0’ is ambiguous In the expression: f p In an equation for ‘it’: it = f p I imagine I somehow need to construct some Proof object using a function g like: > g :: forall (n :: Nat). proxy n -> Proof > g _ = ... Where the Proof constructor encapsulates the (n <= 255) constraint: > data Proof where > NoProof :: Proof > Proof :: forall (n :: Nat). (n <= 255) > => Proxy n -> Proof With g in hand I can construct c which patterns matches on g p and when there's a Proof the (n <= 255) constraint will be in scope which allows applying f to p: > c :: () > c = case g p of > NoProof -> error "Input is bigger than 255!" > Proof p -> f p But how do I define g? Cheers, Bas

4 11

ANNOUNCE: GHC 7.8.4 Release Candidate 1
by Austin Seipp 13 Dec '14

13 Dec '14

We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ This includes the source tarball and bindists for 64bit Linux. Binary builds for other platforms will be available shortly. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.8.4 release sometime in the next few weeks. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

7 6

Defining a custom newByteArray primop that uses calloc?
by Brandon Simmons 26 Nov '14

26 Nov '14

In my tests, using calloc from: https://hackage.haskell.org/package/missing-foreign-0.1.1/docs/Foreign-Mars… was about twice as fast as allocating and zeroing the same amount of memory with `newByteArray` + any of `copy/set/fillMutableByteArray` (all three were nearly identical). Is there a way I can reasonably define my own `newByteArray` that uses calloc? FWIW here are a couple of the benchmarks I'm working with in criterion: arrTestSet :: Int -> IO () arrTestSet len = do let eBytes = (P.sizeOf (undefined::Int))*len a <- P.newAlignedPinnedByteArray eBytes (P.alignment (undefined :: Int)) void $ P.setByteArray a 0 len (1::Int) arrTestCallocAndWrite :: Int -> IO () arrTestCallocAndWrite len = do ptr <- callocBytes (len*(P.sizeOf(undefined::Int))) :: IO (Ptr Int) pokeElemOff ptr 0 1 free ptr Thanks, Brandon

3 2

Type-level Replicate function
by Bas van Dijk 21 Nov '14

21 Nov '14

Hi, tl;dr How do I implement a type-level Replicate function that takes a (n :: Nat) and a type e and produces a type-level list of n e elements. The rest of my email gives some background on why I need this, how it's supposed to be used and my current erroneous implementation. I'm presenting it as a Haskell program: {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} import GHC.TypeLits import Data.Type.Equality import Data.Type.Bool -- For work I'm implementing a binary protocol for -- communicating with some device. I need to be able to send -- a packet of orders to a device. -- -- An order is a list of addresses and command to send to -- these addresses. -- -- After sending the packets of orders the device should -- send back a packet of replies. The packet of replies -- should have a reply for each command send to each -- address. -- -- I would like to make the latter requirement apparent in -- the types so that when I send a packet of orders the type -- will tell me what packet of replies to expect. -- -- So I introduce the OrderPacket type which is -- parameterised with a type-level lists of commands: data OrderPacket (cmds :: [*]) where -- The empty packet: NoOrders :: OrderPacket '[] -- Extending an existing packet with an order. -- -- The (n :: Nat) in Order denotes the number of -- addresses to send the command to. Note that because I -- expect n command replies back I need to create a -- type-level list of n commands and prepend that to the -- existing commands: (:>) :: !(Order n command) -> !(OrderPacket commands) -> OrderPacket (Replicate n command :++: commands) -- As explained, an Order is a vector of addresses of length -- n paired with a command: data Order (n :: Nat) command where Order :: (Command command) => !(Addresses n) -> !command -> Order n command -- In my real implementation this class describes how to -- encode / decode commands: class Command command -- This is the typical Vector of length n type specialised -- to Address: data Addresses (n :: Nat) where Nil :: Addresses 0 (:*:) :: !Address -> !(Addresses n) -> Addresses (n+1) infixr 5 :*: type Address = Int -- Append two type-level lists. type family (rs1 :: [*]) :++: (rs2 :: [*]) :: [*] type instance '[] :++: rs2 = rs2 type instance (r ': rs1) :++: rs2 = r ': (rs1 :++: rs2) -- I'm currently using the following Replicate type-level -- function: type family Replicate (n :: Nat) r :: [*] type instance Replicate (n :: Nat) r = If (n == 0) '[] (r ': Replicate (n-1) r) -- However when I write some code like the following: isNull :: OrderPacket cmds -> Bool isNull NoOrders = True isNull (orderMsg :> orderMsgs) = False -- I get the following error: src/TypeLevelReplicate.hs:49:9: Type function application stack overflow; size = 201 Use -ftype-function-depth=N to increase stack size to N GHC.TypeLits.EqNat (((n-1)-1)-1)...) 0 ~ (((n-1)-1)-1)...) == 0) In the pattern: orderMsg :> orderMsgs In an equation for ‘isNull’: isNull (orderMsg :> orderMsgs) = True Failed, modules loaded: none. -- Note that when I adapt my code to use my own type-level -- inductive implementation of natural numbers like: data N = Z | S N type family Replicate (n :: N) r :: [*] type instance Replicate Z r = '[] type instance Replicate (S n) r = r ': Replicate n r -- I don't get the type function application stack overflow. Any hints on how to make this work with Nats from GHC.TypeLits? Thanks, Bas

2 2

Re: Type-level Replicate function
by Dr. ÉRDI Gergő 21 Nov '14

21 Nov '14

I've replaced the definition of Replicate with a closed type family, and now isNull typechecks on 7.8.2: type family Replicate (n :: Nat) t : [*] where Replicate 0 t = '[] Replicate n t = t ': Replicate (n-1) t On Nov 21, 2014 3:52 PM, "Bas van Dijk" <v.dijk.bas(a)gmail.com> wrote: Hi, tl;dr How do I implement a type-level Replicate function that takes a (n :: Nat) and a type e and produces a type-level list of n e elements. The rest of my email gives some background on why I need this, how it's supposed to be used and my current erroneous implementation. I'm presenting it as a Haskell program: {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} import GHC.TypeLits import Data.Type.Equality import Data.Type.Bool -- For work I'm implementing a binary protocol for -- communicating with some device. I need to be able to send -- a packet of orders to a device. -- -- An order is a list of addresses and command to send to -- these addresses. -- -- After sending the packets of orders the device should -- send back a packet of replies. The packet of replies -- should have a reply for each command send to each -- address. -- -- I would like to make the latter requirement apparent in -- the types so that when I send a packet of orders the type -- will tell me what packet of replies to expect. -- -- So I introduce the OrderPacket type which is -- parameterised with a type-level lists of commands: data OrderPacket (cmds :: [*]) where -- The empty packet: NoOrders :: OrderPacket '[] -- Extending an existing packet with an order. -- -- The (n :: Nat) in Order denotes the number of -- addresses to send the command to. Note that because I -- expect n command replies back I need to create a -- type-level list of n commands and prepend that to the -- existing commands: (:>) :: !(Order n command) -> !(OrderPacket commands) -> OrderPacket (Replicate n command :++: commands) -- As explained, an Order is a vector of addresses of length -- n paired with a command: data Order (n :: Nat) command where Order :: (Command command) => !(Addresses n) -> !command -> Order n command -- In my real implementation this class describes how to -- encode / decode commands: class Command command -- This is the typical Vector of length n type specialised -- to Address: data Addresses (n :: Nat) where Nil :: Addresses 0 (:*:) :: !Address -> !(Addresses n) -> Addresses (n+1) infixr 5 :*: type Address = Int -- Append two type-level lists. type family (rs1 :: [*]) :++: (rs2 :: [*]) :: [*] type instance '[] :++: rs2 = rs2 type instance (r ': rs1) :++: rs2 = r ': (rs1 :++: rs2) -- I'm currently using the following Replicate type-level -- function: type family Replicate (n :: Nat) r :: [*] type instance Replicate (n :: Nat) r = If (n == 0) '[] (r ': Replicate (n-1) r) -- However when I write some code like the following: isNull :: OrderPacket cmds -> Bool isNull NoOrders = True isNull (orderMsg :> orderMsgs) = False -- I get the following error: src/TypeLevelReplicate.hs:49:9: Type function application stack overflow; size = 201 Use -ftype-function-depth=N to increase stack size to N GHC.TypeLits.EqNat (((n-1)-1)-1)...) 0 ~ (((n-1)-1)-1)...) == 0) In the pattern: orderMsg :> orderMsgs In an equation for ‘isNull’: isNull (orderMsg :> orderMsgs) = True Failed, modules loaded: none. -- Note that when I adapt my code to use my own type-level -- inductive implementation of natural numbers like: data N = Z | S N type family Replicate (n :: N) r :: [*] type instance Replicate Z r = '[] type instance Replicate (S n) r = r ': Replicate n r -- I don't get the type function application stack overflow. Any hints on how to make this work with Nats from GHC.TypeLits? Thanks, Bas _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

NOTE: the primary webserver is going down for immediate maintenance.
by Austin Seipp 19 Nov '14

19 Nov '14

Hello *, The primary haskell.org domain, www.haskell.org, is hosted on a system which seems to have lost one of its RAID disks completely. We were planning on moving this machine in the next few weeks to new infrastructure, but we are now expediting this plan and will be doing it ASAP. As we move this server, both the webserver and the mailing system will be going down. Please don't be alarmed if your emails aren't delivered or things go quiet. Many services will continue to work, but we do realize this will be upsetting for many. You can follow the progress on #haskell-infrastructure on Freenode, and see updates on https://status.haskell.org If you need to download something like a GHC binary or Haskell Platform package, you can use https://downloads.haskell.org in the mean time, which is a new service we were hoping to announce more officially soon, but is already working today. Unfortunately we cannot give an expected time of completion for the move, but we'll try to keep people well informed through IRC or something like Reddit. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

RE: The future of the Haskell98 and Haskell2010 packages
by Austin Seipp 18 Nov '14

18 Nov '14

Hello all, A few weeks ago, I opened up a discussion about a particular GHC bug, #9590. This bug is concerned with the future of the Haskell98 and Haskell2010 packages, which try to embody their two respective Haskell standards. They do this by shipping the 'exact library specification' that the standards have. In our discussion this past week between me, SimonM, SPJ, Herbert and Mikolaj, we came to this discussion again since the 7.10 STABLE freeze is almost here, and it seems to have puttered out. In this discussion, we came to the conclusion we think these packages should be removed from GHC for the 7.10 release. To be clear, this was not a 100% unanimous decision or formal vote; SimonM and I supported removal, while everyone else seemed to be rather undecided or ambivalent. Most of the proposed alternative solutions seemed somewhat one-off. Furthermore, we didn't find a solution that wouldn't either A) require some amount of GHC modifications (possibly indefinitely into the future) to support these packages, or B) changing the definitions in these packages to deviate from the standard. Instead, we proposed that we instead overhaul part of the GHC users manual, and clearly outline our deviations from the Haskell 2010 standard library. To be clear: GHC can still typecheck, compile, and efficiently execute Haskell 2010 code. It is merely the distribution of compatible packages that has put us in something of a bind. Furthermore, we aren't aware of any other compilers/platforms like ours that try to maintain such stringent separation of these packages, and furthermore, both of the haskell{98,2010} packages have a fairly small number of reverse dependencies. I'd like to hear what people think about this. It seems likely I will move forward on this by the end of the week unless we face very strong opposition to this idea, or someone is willing to fix #9590 somehow for us. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 4