- Haskell-Cafe - Haskell.org

transformers appears to benefit from more inline
by Oliver Charles 16 Feb '16

16 Feb '16

Hi everyone, I've recently been playing with a little mtl-like approach to streaming data, whereby I have a single type class - MonadYield - which can yield data, and then I use various implementations of this type class to implement operations. My usual approach to this is to implement this by newtyping around appropriate "off-the-shelf" monad transformers from the transformers library, but I found that this incurs a significant performance penalty. I've tried to put some fairly extensive benchmarks in place, which you can find at https://github.com/ocharles/monad-yield. In that repository is a README.md file that describes how I have been performing these benchmarks. The benchmarks are defined over a common interface that each implementation of MonadYield exports. The benchmarks are defined in "Benchmarks.hs", and the three implementations are "Transformers.hs" (using transformers from GHC), "TransformersInline.hs" (using transformers-ocharles from that repository, which has many more INLINE pragmas) and "Inline.hs" (which doesn't depend on anything other than base). There are three main benchmarks that are ran - one is benchmarking essentially the cost of ReaderT, the next the cost of StateT, and the last a composition of ReaderT over StateT over ReaderT. The results of the benchmark can be found here: https://ocharles.github.io/monad-yield/. It seems that the current darcs release of transformers loses every time, but if I sprinkle {-# INLINE #-} across the definition of lazy state, I get identical performance to just writing out the lazy state monad by hand. I was very surprised to see that I have to pay when I use transformers, and it seems like this cost can be removed at the cost of slightly larger interface files. Before I submit a patch, I'd love to hear others thoughts. Should {-# INLINE #-} be necessary? Is there any reason not to add it to every symbol in transformers? -- ocharles

3 2

Catch-22 at GHC bug wiki.
by Doug McIlroy 16 Feb '16

16 Feb '16

Having forgotten my login name, I have had to register at the GHC bug wiki under a different name with a different email address. I see no way for me to clean up the mess. Can anyone tell me how to reach the wiki keepers to get help?

3 2

problem with GHC bug wiki
by Doug McIlroy 15 Feb '16

15 Feb '16

Can anyone tell me how to contact the keepers of the GHC bug wiki about a probem with the wiki--not a GHC ticket? Thanks in advance, Doug

1 0

New type of expressions containing (error ...) includes noisy implicit parameter
by Christopher Allen 15 Feb '16

15 Feb '16

Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default GHCi 8.0 REPL session. I'm glad I caught this before our book goes to print in a couple months. We'd managed to avoid talking about implicit parameters in 1,100+ pages of book but now we're forced to acknowledge their existence in the 4th of 32 chapters. This slipped past the radar more stealthily than the earlier stages of BBP did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for months on end. Was the thinking that people still used implicit parameters for anything or taught them? On the one hand, this is a nice change and something I personally attempted (and failed) to make easier in GHC 7.10. The implementation making the types noisy rankles and didn't seem necessary when I investigated it between 7.8 and 7.10. Could you warn us when (educationally relevant?) stuff like this is coming down the pipe before the RC please? Ideally during the design phase. I think this was discussed as part of FTP to avoid future debacles. This isn't just a pedagogical problem, this is a UX problem. The users don't _care_ that call stack information is being carried around. Why would they? It happens without any mention in the types in almost every other programming language. We checked after the previous thread where ($) occurred in the book. ($) is in the second chapter of the book, which is the first chapter of Haskell code. Now we have to hand-wave something completely impossible for them to understand (chapter 2 is expressions, types are chapter 5) or edit ($) out of the book until they can understand it. We can't write it completely out of the book because ($) gets used all over the place and we don't want encountering it to throw them off. --- Chris Allen

11 21

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Doug McIlroy 14 Feb '16

14 Feb '16

> The DNS as namespace means you have a spot that's guaranteed to be free for your code That's fine at the time, but maintainers come and go while software lives on. A name space that depends on who holds the reins and pays the rent seems rather ephemeral. Doug

3 2

conduit: Inexhaustible source
by David Turner 14 Feb '16

14 Feb '16

Hi, I've got a conduit thing that yields infinitely many values and never exits, which I've given the type ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m Void - a bit like Source m o = ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m () except that it can't exit due to the Void. (One side-question: why is Source m o not ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> Void o m ()?) I would now like to get the first item it yields; I'm currently using Data.Conduit.List.head but of course this returns a Maybe o in case the upstream thing exits. Is there a way to do this without that Maybe? I can't see anything obvious, but nor can I think of a terribly good reason why not. One thing that I was pondering was a kind of fuse operator with a type like ... ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> a b m r1 -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> b c m r2 -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> a c m (Either r1 r2) ... which returns the result of whichever thing exits first. Does such a thing exist? Does it even make sense? If it existed, I think I could use it here as it'd specialise to ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m Void -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> o Void m o -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () Void m (Either Void o) and of course (Either Void o) is isomorphic to o so I'd be home and dry. Having written this, I'm now also struggling to work out what the thing of type ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> o Void m o would be. Maybe I'm going about this all the wrong way, or maybe I'm just confused? Any help greatly appreciated! Cheers, David

2 3

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Johannes Waldmann 13 Feb '16

13 Feb '16

As Manuel wrote: > I expect that every single person teaching Haskell > is going to be unhappy about it. Indeed I am. (Will be teaching beginners next term.) - J.W.

29 75

typeclass for transformation of Euclidean points
by Christopher Howard 13 Feb '16

13 Feb '16

Hi. What I'd like to have for a program I am working on is a generic typeclass for objects that can be treated like points on a 2D plane, and a few simple transform functions (e.g., addition, rotation around an origin) which I could combine to make more complex transformations. Of course, it would be trivial to do this myself, but it seems like the sort of thing somebody would have thought of already. Does anybody know of a package providing this? (I didn't see an obvious one when searching with hoogle.) -- http://justonemoremathproblem.com

2 1

-XGADTs changes type for program that does not contain GADT
by Johannes Waldmann 12 Feb '16

12 Feb '16

Dear Cafe, the following type-correct program does not contain GADT syntax. When I activate GADT language pragma, it does no longer typecheck. {-# language GADTs, ScopedTypeVariables #-} data M a b dw :: (b -> b -> b) -> M a b -> M a b -> M a b dw f x y = x data Bar a b s = Bar { this :: M a (M b s), that :: M b (M a s) } f :: forall p q s . (s -> s -> s) -> Bar p q s -> Bar p q s -> Bar p q s f g x y = let -- diff :: forall p . M p s -> M p s -> M p s diff a b = dw g a b in Bar { this = dw diff (this x)(this y) , that = dw diff (that x)(that y) } I can fix this by declaring the type for `diff` as indicated in the comment. Otherwise, `diff` is not polymorphic (enough), as the error message shows. This behaviour is consistent over ghc-7.8,7.10,8-rc, so it's unlikely to be a bug. But it does seem to go against the claim of "conservative extension of HM" (Sect 6.6 of the ICFP'06 paper, Sect 4.9 of MS-CIS-05-26) http://research.microsoft.com/en-us/um/people/simonpj/papers/gadt/ - J.W.

3 2

FLTKHS on WIndows- Call for Help.
by aditya siram 12 Feb '16

12 Feb '16

Hi all, I am the author and maintainer of FLTKHS [1] a cross-platform GUI binding and I could use some help getting it installed on Windows. When I cut a release this past October it was working well on Windows 7 with MinGHC and CMake[2]. Unfortunately MinGHC is now no longer supported and I haven't had much luck getting it to work on with Stack and the mingw that now ships with recent versions GHC. The Stack team is not to blame, I am very much a noob on Windows. I have also recently lost access to my (woefully out-dated) Windows 7 box. As it stands FLTKHS does not work on GHC > 7.10.2 since that is the version supported by the final release of MinGHC. In short, if you are currently using this package on Windows with Stack, please tell me how you got it working. If not and you would benefit from this package could you give it a try and report back? It doesn't have to be a full write up or anything, just a short overview of what you did would be great. When I hear back I'll borrow a machine, try it out, update the documentation and cut another release. Thanks! -deech [1] http://hackage.haskell.org/package [2] http://hackage.haskell.org/package/fltkhs-0.4.0.2/docs/Graphics-UI-FLTK-Low…

1 0