January 2016 - Haskell-Cafe

7.10.3 source link missing
by aditya siram 13 Jan '16

13 Jan '16

Hi all, Just wanted to make haskell.org maintainers aware that 7.10.3 release does not provide a link to the source distribution on the Download page. https://www.haskell.org/ghc/download_ghc_7_10_3#sources. Thanks! -deech

1 1

New release of the book Haskell Programming from first principles
by Christopher Allen 12 Jan '16

12 Jan '16

I'd been reticent in the past to announce the book on the mailing list, but it's pretty comprehensive now and we have enough ecstatic readers learning Haskell with it that I thought I'd share what we've been up to. We're writing this Haskell book (http://haskellbook.com/) because many have found learning Haskell to be difficult and it doesn't have to be. We have a strong focus on writing it to be a book for learning and teaching - it's not just a reference or review of topics. Particularly, we strive to make the book suitable for self-learners. We think Haskell is a really nice language and learning Haskell should be as nice as using it is. The new release puts the book at 26 chapters and 1,156 pages. You can track our progress here: http://haskellbook.com/progress.html The latest release included parser combinators, composing types, and monad transformers. My coauthor Julie Moronuki has never programmed before learning Haskell to work with me on this book. She has written about using the book to teach her 10 year old son as well - https://superginbaby.wordpress.com/2015/04/08/teaching-haskell-to-a-10-year… Julie has also written about learning Haskell more generally - https://superginbaby.wordpress.com/2015/05/30/learning-haskell-the-hard-way/ If you've been reading the book, please speak up and share your thoughts. We have some reader feedback on the site at http://haskellbook.com/feedback.html We'll be looking for a press to do a print run of the book soon as it's about 80% done. If anyone has any pointers or recommendations on whom to work with, particularly university presses, please email me. Cheers everyone, Chris Allen

6 8

Why does shift's function return result in Cont and reset reinsert result into Cont again?
by Dmitriy Matrosov 12 Jan '16

12 Jan '16

Hi. I've read "Introduction to Programming with Shift and Reset" by Kenichi Asai and Oleg Kiselyov , where shift and reset defined as > import Control.Monad.Cont > > shift :: ((a -> w) -> Cont w w) -> Cont w a > shift f = cont (flip runCont id . f) > > reset :: Cont a a -> Cont w a > reset = return . flip runCont id > > shiftT :: Monad m => ((a -> m w) -> ContT w m w) -> ContT w m a > shiftT f = ContT (flip runContT return . f) > > resetT :: Monad m => ContT a m a -> ContT w m a > resetT = lift . flip runContT return But why should function f return result in Cont, which i'll unwrap immediately? And why should i reinsert delimited continuation's result into Cont again in reset? Wouldn't it be simpler (better?) to just define shift/reset like > shift' :: ((a -> w) -> w) -> Cont w a > shift' = cont > > reset' :: Cont w w -> w > reset' m = runCont m id > > shiftT' :: ((a -> m w) -> m w) -> ContT w m a > shiftT' = ContT > > resetT' :: Monad m => ContT w m w -> m w > resetT' m = runContT m return Moreover, Bubble-up semantics proof of Cont bubble elimination is (literally) correct only with reset' (below is my bubble implementation, may be i've written it wrong?): > data Bubble w a b = Bubble (a -> Bubble w a b) ((a -> w) -> Bubble w a w) > | Value b > > instance Monad (Bubble w a) where > return x = Value x > Value x >>= h = h x > Bubble k f >>= h = Bubble (\x -> k x >>= h) f > > convBub'2 :: Bubble w a b -> Cont w b > convBub'2 (Value x) = return x > convBub'2 (Bubble k f) = cont $ \t -> runCont (fC (\x -> runCont (kC x) t)) id > where > --fC :: (a -> w) -> Cont w w > fC = convBub'2 . f > --kC :: a -> Cont w b > kC = convBub'2 . k > > bubbleResetProp :: Eq w => Bubble w a w -> Bool > bubbleResetProp b@(Value x) = reset' (convBub'2 b) == x > bubbleResetProp b@(Bubble k f) = > reset' (convBub'2 b) == reset' (fC (\x -> reset' (kC x))) > where > --fC :: (a -> w) -> Cont w w > fC = convBub'2 . f > --kC :: a -> Cont w b > kC = convBub'2 . k > > infixl 0 === > (===) :: a -> a -> a > (===) = const > > bubbleResetProof :: Bubble w a w -> w > bubbleResetProof (Bubble k f) = > reset' (cont $ \t -> runCont (fC (\x -> runCont (kC x) t)) id) > === runCont (cont $ \t -> runCont (fC (\x -> runCont (kC x) t)) id) id > === (\t -> runCont (fC (\x -> runCont (kC x) t)) id) id > === runCont (fC (\x -> runCont (kC x) id)) id > === reset' (fC (\x -> reset' (kC x))) > where > --fC :: (a -> w) -> Cont w w > fC = convBub'2 . f > --kC :: a -> Cont w b > kC = convBub'2 . k -- Dmitriy Matrosov

2 1

Re: [Haskell-cafe] New release of the book Haskell Programming from first principles
by Johannes Waldmann 12 Jan '16

12 Jan '16

Chris - Impressive amount of work! Since this is "cafe" ... allow me to put my standard rant here: Browsing your table of contents, I certainly agree that lambda calculus is a first principle. But when I teach (beginners or not) I put algebraic data types and pattern matching even before functions. Because I want to first describe data, then transformation of data. (Yes, I know, we can simulate data with functions. We can also simulate lambda calculus with term rewriting. No winner there..) And testing really should go as early as possible (lecture 1 or 2, ideally). I don't really know how to do this from first principles and early, because we need some type-classes here (deriving Eq and Show, and also Serial, for automated test case generation. Which should be a strong selling point.) And I do avoid numbers, lists and strings. Really. Functional programming tragically over-uses lists, and by extension, strings. (Of course, other languages also tragically over-use strings.) When I need a list, I have the students write down the data declaration. When I need numbers (mostly I don't), it's Peano numbers. Yes, lazy lists have a purpose in Haskell (expressing control) but this only works if they're being fused away. Later, when we have modules and type classes (for abstract data types), students can learn to use different representations for sequences. But if you start feeding them lists/strings, they'll think it's natural, and have a hard time switching to Data.Sequence, Data.Vector, Data.Text ... I know I did. Well. I'm sure you've given this a lot of thought. I see that you refer to Brent Yorgey's course https://github.com/bitemyapp/learnhaskell#yorgeys-cis194-course and there we have "data"/"case" in lecture 2. Oh, and I do have to read up on how he sells Applicative/Monad. For me, Monad feels more natural, but that's just because I learned it earlier, and now I have to unlearn it. And that illustrates the point I'm making about lists and strings. Best - Johannes.

2 1

Data declaration vs type classes
by Lian Hung Hon 11 Jan '16

11 Jan '16

Dear haskellers, What is the difference between writing data Task = GroceryTask String | LaundryTask Int doTask :: Task -> IO () doTask (GroceryTask s) = print "Going to " ++ s doTask (LaundryTask n) = print (show n ++ " pieces washed" and class Task a where work :: a -> IO () data GroceryTask = GroceryTask String data LaundryTask = LaundryTask Int instance Task GroceryTask where .. instance Task LaundryTask where .. doTask :: Task a => a -> IO () doTask = work They seem to be similar functionality wise, except that one is on the data level and another is on the class level. How should one go about deciding to use data or class? Is there a semantic difference? Which is more appropriate here? Happy new year, Hon

8 11

[RFC] github-0.14.0 release candidate
by Oleg Grenrus 11 Jan '16

11 Jan '16

Hi, There are lot of breaking changes In upcoming github package, which provides accoss to the Github API, v3 [1] I’d like to hear feedback before pushing the actual release. There are many breaking changes, and would be nice to avoid new breaking changes very soon. So if you spot something which can still be fixed, don’t hesitate to contact me or create a issue on Github [3]. You can find the release candidate at Hackage [2]. Cheers, Oleg Grenrus - [1]: https://developer.github.com/v3/ - [2]: http://hackage.haskell.org/package/github-0.14.0/candidate - [3]: https://github.com/phadej/github/issues

1 0

Promotion of field accessors using DataKinds
by William Yager 11 Jan '16

11 Jan '16

Hello all, Let's say I have some data data Config = Conf (len :: Nat) (turboEncabulate :: Bool) Using DataKinds, we can promote Config to a kind and Conf to a type. However, it does not appear that GHC supports e.g. data Thing (conf :: Config) = Thing data Count (n :: Nat) = Count foo :: Thing conf -> Count (len conf) foo Thing = Count That is, it does not appear to properly replace "len conf" with the value of len from conf. Instead, the way I've found to do this is to define class Lengthed (a :: Config) where type Len a :: Nat instance Lengthed (Conf n) where type Len (Conf n t) = n Now, foo :: Thing conf -> Count (Len conf) works fine. So manually defining a type function that intuitively does the exact same thing as "len" seems to work. Is there a particular reason behind this? Thanks, Will

2 1

Merging the OpenGLRaw and gl packages
by Sven Panne 11 Jan '16

11 Jan '16

Currently there are 2 similar packages on Hackage to access raw OpenGL functionality: OpenGLRaw and gl. Taking a closer look at them, it turns out that they are only superficially different and have a lot of things in common. This is a bit confusing for users, so it might make sense to merge those packages. Therefore I'd like to start a discussion how to do this in detail, collecting user feedback and opinions. I think that haskell-cafe is the right place for this discussion, while an accompanying wiki page is more suitable to collect the results. As a basis I started a page at https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl, which is necessarily biased at the moment. ;-) It would be nice to hear your opinions about how the package should look like, what might be missing, what could be done better, which differences I forgot, etc. Cheers, S.

3 9

ANN: true-name 0.1.0.0 released
by Liyang HU 10 Jan '16

10 Jan '16

> Also sent to comp.lang.haskell, & to convince Gmane I'm not top-posting. It is with some shame that I announce ‘true-name’, a package to assist one in violating those pesky module abstraction boundaries via the magick of Template Haskell. http://hackage.haskell.org/package/true-name Take ‘Control.Concurrent.Chan’ for example; you can get your grubby mitts on the ‘Chan’ data constructor, despite it not being exported. Here we pattern match on it, and bind ‘chanR’ and ‘chanW’ to the ‘MVar’s containing the read and write ends of the channel respectively: > chan@[truename| ''Chan Chan | chanR chanW |] <- newChan > writeChan chan (42 :: Int) Now, the type of ’chanR’ references the unexported ‘Stream’ and ‘ChItem’ types. We need the ‘ChItem’ data constructor―which is hidden under a few indirections—but that's not a problem: > streamR <- readMVar chanR > [truename| ''Chan Chan Stream ChItem ChItem | x _ |] <- readMVar streamR > putStrLn $ "chan contains: " ++ show x This gives us a rather dodgy ‘peekChan’. This sort of thing is usually a Bad Idea™, but may sometimes be more palatable than the alternatives. Full example: https://github.com/liyang/true-name/blob/master/sanity.hs Taking another example, suppose we want the ‘Array’ type constructor hidden deep in the bowels of the ‘HashMap’ implementation: ghci> :set -XQuasiQuotes ghci> import Data.HashMap.Strict ghci> :kind [truename| ''HashMap Full Array |] [truename| ''HashMap Full Array |] :: * -> * The ‘Array’ data constructor is one more reification away: ghci> :type [truename| ''HashMap Full Array Array |] [truename| ''HashMap Full Array Array |] :: ghc-prim-0.4.0.0:GHC.Prim.Array# a -> unordered-containers-0.2.5.1:Data.HashMap.Array.Array a Please don't flame me. /Liyang

1 0

pattern matching v. type checking
by Jeffrey Brown 10 Jan '16

10 Jan '16

I am, thanks to an idea from Elliot Cameron, using the Functional Graph Library (FGL) to implement [1] something resembling a hyperggraph, which I'm calling Mindmap, in which relationships can involve any number of things, including other relationships. (By contrast, in a graph, Edges cannot belong to other Edges; only Nodes can.) Here are the types: -- Exprs (expressions) play Roles in Rels (relationships). -- A k-ary (Arity k) Rel consists of a k-ary template and k members. -- Each k-ary Rel emits k+1 Edges toward the other Exprs: -- one connects it to its RelTplt (relationship template) -- k more connect it to each of its k RelMbrs (relationship members) -- The two paragraphs after it will clear up any questions about the next. type Mindmap = Gr Expr Role data Role = RelTplt | RelMbr RelPos deriving (Show,Read,Eq,Ord) data Expr = Str String | Tplt Arity [String] | Rel Arity -- TODO ? deduce the Arity of a Tplt from its [String] -- TODO ? deduce from the graph the Arity of a Rel -- rather than carrying it redundantly in the Rel constructor deriving (Show,Read,Eq,Ord) type RelPos = Int -- the k members of a k-ary Rel take RelPos values [1..k] type Arity = Int The following is a Mindmap that represents the expression "dog needs water" using the subexpressions "dog" (a string), "water" (a string), and "_ wants _" (a relationship two things can have, that is a binary Rel): -- mkGraph :: Graph gr => [LNode a] -> [LEdge b] -> gr a b -- that is, mkGraph takes a list of nodes followed by a list of edges g1 :: Mindmap g1 = mkGraph [ (0, Str "dog" ) , (1, stringToTplt "_ wants _" ) -- produces a Tplt with Arity 2 , (3, Str "water" ) , (4, Rel 2 ) ] [ -- "dog wants water" (4,1, RelTplt) -- Node 1 is the Template for the Rel at Node 4 , (4,0, RelMbr 1) -- Node 0 is the 1st Rel Member of the Rel at Node 4 , (4,3, RelMbr 2) -- Node 3 is the 2nd Rel Member of the Rel at Node 4 ] The next Mindmap encodes the previous statement and a second statement stating that the first is dubious: g2 :: Mindmap g2 = mkGraph [ (0, Str "dog" ) , (1, stringToTplt "_ wants _" ) , (3, Str "water" ) , (4, Rel 2 ) , (5, stringToTplt "_ is _") , (6, Str "dubious" ) , (7, Rel 2 ) ] [ -- "dog wants water" is represented just like it was in g1 (4,1,RelTplt), (4,0, RelMbr 1), (4,3,RelMbr 2), -- "[dog wants water] is dubious" (7,5,RelTplt), (7,4,RelMbr 1), -- Node 4, the first Member of this Rel, is itself a Rel (7,6,RelMbr 2) ] I find myself doing a lot of pattern matching that maybe should be type checking instead, to distinguish between the three Expr constructors: For instance, here is a function that, given a Node at which there is a Rel, returns the Tplt for that Rel: tpltForRelAt :: (MonadError String m) => Mindmap -> Node -> m Expr tpltForRelAt g rn = do ir <-isRel g rn if not ir then throwError $ "tpltForRelAt: Label of LNode " ++ show rn ++ " is not a Rel." else return $ fromJust $ lab g $ head [n | (n,RelTplt) <- lsuc g rn] -- todo ? head is unsafe -- but is only unsafe if graph takes an invalid state -- because each Rel should have exactly one Tplt I had to manually check whether the Expr in question was a Rel. I feel like I'm doing the type system's job. Is there a better way? [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text -- Jeffrey Benjamin Brown

1 0