- Glasgow-haskell-users

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1
by Mikolaj Konarski 13 Dec '14

13 Dec '14

OK. In that case, let's remember to get *that* version of cabal into 7.8.4. /me conditions himself with chocolate to help the remembering On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel <ttuegel(a)gmail.com> wrote: > On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski > <mikolaj(a)well-typed.com> wrote: >> On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald >> <carter.schonwald(a)gmail.com> wrote: >>> Thomas and I have found some bugs in HPC on OSX, and we're in the midst of >>> tracking those down, >> >> You mean these are regressions? If they are introduced >> in one of the non-blocker fixes in 7.8.4, we can probably >> just revert them. Anyway, thanks a lot for testing. > > Sorry, these are not regressions. It's really a bug in Cabal which > will be fixed in 1.22. When Carter wrote this, we thought the problem > was with the GHC side of HPC because of some very vague error > messages. > > -- > Thomas Tuegel >

1 0

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

confusing type error
by Evan Laforge 10 Dec '14

10 Dec '14

I recently got a confusing error msg, and reduced it to a small case: f1 :: Monad m => m Bool f1 = f2 0 0 'a' f2 :: Monad m => Int -> Float -> m Bool f2 = undefined >From this, it's clear that f2 is being given an extra Char argument it didn't ask for. However, the error msg (ghc 7.8.3) is: Couldn't match type ‘m Bool’ with ‘Bool’ Expected type: Char -> m Bool Actual type: Char -> Bool Relevant bindings include f1 :: m Bool (bound at Bug.hs:4:1) The function ‘f2’ is applied to three arguments, but its type ‘Int -> Float -> Char -> Bool’ has only three In the expression: f2 0 0 'a' In an equation for ‘f1’: f1 = f2 0 0 'a' The confusing part is that 'f2' was applied to three arguments, but it's type has only three. It includes the Char in expected and actual types, and implies that the type of 'f2' includes the Char. So I took quite a while to realize that the type of 'f2' in fact *didn't* expect a Char (and had an 'm'), so that the "but its type" is *not* in fact its declared type. I suppose it infers a type for 'f2' based on its use, and that then becomes the "actual" type, but it seems less confusing if it picked the declared type of 'f2' as its actual type. Perhaps this is working as intended, but it it is confusing! Especially the part about "expected three but got three". Ideally I'd like to see "too many arguments" or at least "expected (Char -> m Bool) but actually 'm Bool'". Actually I'd expect the other way: "expected 'm Bool' but got (Char -> m Bool)' but I think ghc has always done it backwards from how I expect. It looks like it's substituting (->) for 'm', so maybe it's one of those things where ((->) a) is also a monad.

6 9

Re: New implementation draft for -XStaticPointers
by John Wiegley 02 Dec '14

02 Dec '14

>>>>> Facundo Domínguez <facundo.dominguez(a)tweag.io> writes: > We are pleased to announce a new implementation draft of the > StaticPointers extension [1]. Very nice, thank you! John

2 1

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

27 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

More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Merijn Verstraaten 16 Nov '14

16 Nov '14

As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation. Unless there's any vehement objections, I'll produce a diff on fabricator asap. Cheers, Merijn

3 5