- Haskell-Cafe - Haskell.org

[ANN] thirdake-0.1 the Makefile-like DSL
by Sergey Mironov 29 Jul '13

29 Jul '13

Hi, cafe. Neil Mitchell mentioned more than ten build systems written in Haskell in his paper [1]. The list includes shake (of cause) Abba, Coadjuke, hake, hmk, and even two cakes. I'm glad to announce the thirdcake - a DSL for make language. Thirdcake allows user to produce clean and safe (I hope) Makefiles for the good old GNU make. The package is in it's early stages and is not on Hackage yet. Consider visiting https://github.com/grwlf/cake3 or just git clone https://github.com/grwlf/cake3 ./Example/Foo contains working toy-project demonstrating the approach. Regards, Sergey [1] - http://community.haskell.org/~ndm/downloads/paper-shake_before_building-10_… PS My English is still buggy, feel free to patch the grammar as well as the rest

1 0

using network+conduit+tls for a client application?
by Petr Pudlák 29 Jul '13

29 Jul '13

Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Thank you, Petr Pudlak

4 4

Is withAsync absolutely safe?
by Roman Cheplyaka 29 Jul '13

29 Jul '13

Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () -> IO ThreadId) -> IO a -> (Async a -> IO b) -> IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner -> do var <- newEmptyTMVarIO mask $ \restore -> do t <- doFork $ try (restore action) >>= atomically . putTMVar var let a = Async t (readTMVar var) r <- restore (inner a) `catchAll` \e -> do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Roman

2 2

Munich Haskell Meeting
by Heinrich Hördegen 29 Jul '13

29 Jul '13

Dear all, our monthly Haskell Meeting will take place tomorrow, Tuesday the 30th of July, at 19h30 in Munich. Please note that we will meet at Max-Emanuel-Brauerei. If you plan to join, please hit the button at http://www.haskell-munich.de/dates Have a nice week, Heinrich

1 0

haskell-gtk entry question
by briand＠aracnet.com 28 Jul '13

28 Jul '13

Hello all, This should be simple, and I thought it had it working, but I've broken it and can't figure out why. What I want is to invoke the callback whenever the user activates and entry in a dialogbox, so I did both this : Gtk.on entry Gtk.entryActivate (boxHandler entry) (I believe this supercedes the previous method which was onEntryActivate) and this Gtk.on entry Gtk.entryPreeditChanged (boxHandler entry) however neither method will invoke the callback. The program compiles and works just fine, it's just that the callback never runs. Thank you, Brian

2 2

casting a into Maybe a
by Joerg Fritsch 27 Jul '13

27 Jul '13

If I have the following type signature transMit :: Serialize a => Socket -> POSIXTime -> KEY -> Maybe a -> TPSQ -> TMap a -> IO () And the function is called with transMit s now key newmsgs q m where newmsgs is whatever type a I get but _not_ a Maybe a then I get the error Could not deduce (a ~ Maybe a) from the context (Serialize a) Can I somehow when I call transmit cast newmsgs into a Maybe newmsgs or so so that the function call fits the type signature? --Joerg

2 1

scrz - container management tool written (partly) in haskell
by Tomas Carnecky 27 Jul '13

27 Jul '13

Scrz (http://scrz.io) is a container (LXC) management tool. It is heavily inspired by docker and heroku, but also provides features which those two don't have. It comes in two parts, one is the supervisor which manages the containers, the other is a server which stores the configuration. The supervisor fetches its configuration from the server. Only the supervisor is written in Haskell, the configuration server is written in Ruby on Rails. I use scrz on my personal server, and it's also used to automate deployments of http://encounter.io (another side project that I have). I just recently updated the homepage and redesigned the configuration server UI (screenshot link at the bottom). It's more difficult to set up than docker, and not that well integrated into the system. This is partly due to lack of good low-level sysadmin libraries for Haskell (eg. to list/create/inspect network interfaces) and partly due to dependencies on new versions of software that are not even available in the latest stable ubuntu (lxc-tools version 0.9.x). The project is maintained on github: https://github.com/scrz. http://cl.ly/image/262v1x1r2T12

1 0

Are type families really this slow, or is this a GHC bug?
by Mike Izbicki 27 Jul '13

27 Jul '13

I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies. It's doing in quadratic time what looks to me like it should be linear time. I don't know if this is expected behavior, if I'm doing something wrong, or if this is a GHC bug. I've attached a code sample below that demonstrates the problem. Types.hs generates other haskell files. The first parameter is the size of the type (which is type list of that length), and the second specifies which test to run. All tests generate the same type in the end, but some use type families and some don't. Here's an example of running it: These tests show quadratic time when using the type family. I have to increase the context stack size to be greater than the recursion depth of the type family. I don't know if this is a bad sign or to be expected. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ ghc Types $ ./Types 200 a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=250 real 0m2.973s $ ./Types 300 a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=350 real 0m6.018s $ ./Types 400 a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=450 real 0m9.995s $ ./Types 500 a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=550 real 0m15.645s Without the type family, I get MUCH better performance: $ ./Types 10000 d > test.hs && time ghc test.hs > /dev/null real 0m2.271s ------------------------ -- Types.hs below ------------------------ import System.Environment code :: Int -> String -> String code i test = concat $ map (++"\n") $ [ "{-# LANGUAGE TypeOperators,DataKinds, KindSignatures,TypeFamilies,PolyKinds #-}" , "import GHC.TypeLits" , "data Nat1 = Zero | Succ Nat1" , "type family Replicate1 (n :: Nat1) (x::a) :: [a]" , "type instance Replicate1 Zero x = '[]" , "type instance Replicate1 (Succ n) x = x ': (Replicate1 n x)" , "class Class a where" , " f :: a -> a" , "data Data (xs::a) = X | Y" , " deriving (Read,Show)" , "main = print test1" ] ++ case head test of 'a' -> [ "instance (xs ~ Replicate1 ("++mkNat1 i++") ()) => Class (Data xs) where" , " f X = Y" , " f Y = X" , "test1 = f (X :: Data ( Replicate1 ("++mkNat1 i++") () ))" ] 'b' -> [ "instance (xs ~ ("++mkList i++") ) => Class (Data xs) where" , " f X = Y" , " f Y = X" , "test1 = f (X :: Data ( Replicate1 ("++mkNat1 i++") () ))" ] 'c' -> [ "instance (xs ~ Replicate1 ("++mkNat1 i++") ()) => Class (Data xs) where" , " f X = Y" , " f Y = X" , "test1 = f (X :: Data ( ("++mkList i++") ))" ] otherwise -> [ "instance (xs ~ ("++mkList i++") ) => Class (Data xs) where" , " f X = Y" , " f Y = X" , "test1 = f (X :: Data ( ("++mkList i++") ))" ] mkList :: Int -> String mkList 0 = " '[] " mkList i = " () ': " ++ mkList (i-1) mkNat1 :: Int -> String mkNat1 0 = " Zero " mkNat1 i = " Succ ( " ++ mkNat1 (i-1) ++ ")" main = do numstr : test : xs <- getArgs let num = read numstr :: Int putStrLn $ code num test

2 2

Sneaky method for var-arg fns?
by Micah Cowan 26 Jul '13

26 Jul '13

So, just for fun, I came up with a way to abuse the language in order to define a "function" whose argument is optional: > -- dirty-trick.hs - A sneaky way to do var args fns in Haskell > > {-# LANGUAGE FlexibleInstances #-} > > class Hello a where > hello :: a > > instance Hello (String -> String) where > hello = (\str -> "Hello " ++ str) > > instance Hello String where > hello = hello "World" In ghci, putStrLn $ hello gives "Hello World", while putStrLn $ hello "There" gives "Hello". . I was wondering if there was a way to do it in "pure" Haskell (i.e., no GHC pragmas required), and also the specific reason for why the above example doesn't work without the pragma (I think it's just that in general a -> b is not syntactically allowed for type specifiers within instance declarations)? I'm also interested in alternative approaches to creating variable-argument functions, if there are any. . If anyone's curious, this was prompted by a discussion with a friend (copied), about Haskell and Clojure. He mentioned that Clojure can accept variable arguments, though AFAICT all Clojure functions basically act like they take a list (that supports variable types), so accepting an empty argument list is a bit analogous to Haskell accepting an empty list, rather than no arguments. Part of the reason Haskell can't really take "variable arguments" is that all Haskell functions really just take one argument. But I figured you could use the contextually expected type to decide whether to return a simple value (not /technically/ a function in that case), or a function expecting further arguments, which could then be extended to define a function taking any arbitrary number of arguments. Cheers! -mjc

4 3

Proposal: Non-recursive let
by oleg＠okmij.org 26 Jul '13

26 Jul '13

Jon Fairbairn wrote: > It just changes forgetting to use different variable names because of > recursion (which is currently uniform throughout the language) to > forgetting to use non recursive let instead of let. Let me bring to the record the message I just wrote on Haskell-cafe http://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html and repeat the example: In OCaml, I can (and often do) write let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about 50-100 lines of code with the fragment like the above and the only problem was my messing up the numbering (at one place I used s2 where I should've used s3). In the chain of lets, it becomes quite a chore to use different variable names -- especially as one edits the code and adds new let statements. I have also had problems with non-termination, unintended recursion. The problem is not caught statically and leads to looping, which may be quite difficult to debug. Andreas should tell his story. In my OCaml experience, I don't ever remember writing let rec by mistake. Occasionally I write let where let rec is meant, and the type checker very quickly points out a problem (an unbound identifier). No need to debug anything. Incidentally, time and again people ask on the Caml list why 'let' in OCaml is by default non-recursive. The common answer is that the practitioners find in their experience the non-recursive let to be a better default. Recursion should be intended and explicit -- more errors are caught that way. Let me finally disagree with the uniformity principle. It may be uniform to have equi-recursive types. OCaml has equi-recursive types; internally the type checker treats _all_ types as (potentially) equi-recursive. At one point OCaml allowed equi-recursive types in user programs as well. They were introduced for the sake of objects; so the designers felt uniformly warrants to offer them in all circumstances. The users vocally disagreed. Equi-recursive types mask many common type errors, making them much more difficult to find. As the result, OCaml developers broke the uniformity. Now, equi-recursive types may only appear in surface programs in very specific circumstances (where objects or their duals are involved). Basically, the programmer must really intend to use them. Here is an example from the natural language, English. Some verbs go from regular (uniform conjugation) to irregular: http://en.wiktionary.org/wiki/dive

19 40