June 2010 - Haskell-Cafe

checking types with type families
by Evan Laforge 08 Jul '10

08 Jul '10

I have a parameterized data type: > data Val result = VNum Double | VThunk (SomeMonad result) > type Environ result = Map Symbol (Val result) I have a class to make it easier to typecheck Vals: > class Typecheck a where > from_val :: Val result -> Maybe a > > instance Typecheck Double where > from_val (VNum d) = Just d > from_val _ = Nothing Now I can write > lookup_environ :: (Typecheck a) => Symbol -> Environ result -> Maybe a Now of course there's a question of how to write Typecheck for VThunk. I would like to be able to call 'lookup_environ' expecting a 'SomeMonad result' and get Nothing or Just depending on if it's present. > instance Typecheck (SomeMonad result) where > from_val (VThunk f) = Just f But I need something to say that the 'result' from the instance head is the same as the 'result' from the class declaration, because otherwise I get Couldn't match expected type `result' against inferred type `result1' So maybe a type family? > class Typecheck ... > type ResultOf a :: * > from_val :: Val (ResultOf a) -> Maybe a > > instance Typecheck (SomeMonad result) where > type ResultOf (SomeMonad result) = result > ... Now the question is, what's the ResultOf a Double? Well, since the output doesn't depend on 'result' at all, I would like to be able to write 'type ResultOf Double = anything', and then I can look up a VNum in an 'Environ anything'. Unfortunately, that type declaration isn't legal because it wants 'anything' to be bound somewhere. I tried explicitly introducing 'anything' with a forall, but no dice. So there are a number of possible solutions to this problem. One is, is there another way to get from the expression language type VNum, VThunk, etc. to a haskell type that doesn't use typeclasses in this way? Or, is there a way to assert in the instance of 'Typecheck (SomeMonad result)' that its 'result' is equal to the 'result' in the class declaration without using type families in this way? Or, is there a way to use type families in the way I'm using them to leave 'result' polymorphic in the cases where it can be left free in the result (e.g. VNum 42 :: Val anything)? I know lots of people have used haskell to write little interpreters, so maybe someone has solved this problem before. Basically, I have a Val that is "semi-polymorphic", but even if I go the totally monomorphic / dynamic type route by making a Result type with all the different types, I still have trouble converting from haskell types and back when I need to write the "Result -> result" function. I suppose I could play the same Typecheck game there, but I like the idea of an "Environ X" that doesn't admit the wrong kind of VThunk. It seems like I should be able to express that in the type system and be safer as well as save some packing and unpacking.

12 24

CGI differences FastCGI
by Jonas Fager 06 Jul '10

06 Jul '10

Hi. This is probably "I must be blind department" I have a very basic strip down echo cgi that runs with apache2. When I try to modfi it to be a FastCGI instead and run it with spawn-fcgi with nginx It don't behave as expected. I suppose that the line that don't get any data is mn <- getInputFPS "file" when running under FastGCI. So is the code wrong? or have I missed something with the setup? I can run the example of fastcgi provided in http://mult.ifario.us/p/wiring-haskell-into-a-fastcgi-web-server with no problem. Description: Ubuntu 10.04 LTS 2.6.32-22-generic-pae #36-Ubuntu SMP The Glorious Glasgow Haskell Compilation System, version 6.12.1 +++++ import Control.Concurrent import Network.CGI -- import Network.FastCGI import Text.Html import qualified Data.ByteString.Lazy as BS import qualified Data.ByteString.Lazy.Char8 as BS8 import Control.Monad (liftM) import Data.Maybe (fromJust) import Char import Data.List import System.Time import qualified Data.ByteString.Char8 as C import Text.JSON.Generic import Text.JSON insertthis fb = do let f = BS8.unpack fb return (f) fileForm = form ! [method "post", enctype "multipart/form-data"] << [textfield "file", submit "" "Upload"] saveFile cont = do r<-liftIO $ insertthis cont return $ paragraph << ("Inserted " ++ (show r)) page t b = header << thetitle << t +++ body << b test :: CGI CGIResult test = do setHeader "Content-Type" "text/html; charset=utf-8" mn <- getInputFPS "file" h <- maybe (return fileForm) saveFile mn output $ renderHtml $ page "Upload" h main = runCGI $ handleErrors test --main= runFastCGI $ handleErrors test +++++

2 1

Please check your dependencies on fgl
by Ivan Miljenovic 06 Jul '10

06 Jul '10

Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. As such, if your code uses fgl you should ensure that the specification of the package in your .cabal file has an explicit upper bound (or indeed just set "fgl == 5.4.2.2") to avoid any problems when we release 6.0.0.0 (we're trying to avoid the problems that plagued KDE-4 by not claiming in the slightest that the initial few versions are intended for end users). I have already directly emailed the maintainers of any and all packages I could find on Hackage (using Roel van Dijk's wonderful reverse-dependency mirror at http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html) but just in case I've missed one or there's an as-yet-unreleased package somewhere in the works, here is the official "heads up". -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

17 43

How easy is it to hire Haskell programmers
by Paul Johnson 05 Jul '10

05 Jul '10

I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with. However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this. * How many applications did you get? * How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell? Thanks, Paul.

27 53

Mining Twitter data in Haskell and Clojure
by braver 04 Jul '10

04 Jul '10

I'm computing a communication graph from Twitter data and then scan it daily to allocate social capital to nodes behaving in a good karmic manner. The graph is culled from 100 million tweets and has about 3 million nodes. First I wrote the simulation of the 35 days of data in Clojure and then translated it into Haskell with great help from the glorious #haskell folks. I had to add -A5G -K5G to make it work. It does 10 days OK hovering at 57 GB of RAM; I include profiling of that in sc10days.prof. At first the Haskell executable goes faster than Clojure, not by an order of magnitude, but by 2-3 times per day simulated. (Clojure also fits well in its 32 GB JVM with compressed references.) However, Haskell gets stuck after a while, and for good. Clearly I'm not doing Haskell optimally here, and would appreciate optimization advice. Here's the code: http://github.com/alexy/husky The data and problem description is in http://github.com/alexy/husky/blob/master/Haskell-vs-Clojure-Twitter.md -- also referred from the main README.md. The main is in sc.hs, and the algorithm is in SocRun.hs. The original Clojure is in socrun.clj. This is a continuation of active Twitter research and the results will be published, and I'd really like to make Haskell work at this scale and beyond! The seq's sprinkled already did no good. I ran under ghc 6.10 with -O2 with or without - fvia-C, with no difference in stallling, and am working to bring 6.12 to bear now. Cheers, Alexy

15 41

Parsec combinator like Prolog's cut operator?
by Erik de Castro Lopo 03 Jul '10

03 Jul '10

Hi all, I'm reading John Hughes' paper "Generalizing Monads to Arrows" and found the statement regarding parser combinators: "... depend on the programmer using an additional combinator similar to Prolog's 'cut' operator do declare that a parser need never backtrack beyond a certain point." Does something like this already exist in Parsec? If not is there a way to write it? Having this would really help with a parsing problem I have. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

6 7

GHCi and State
by corentin.dupont＠ext.mpsa.com 02 Jul '10

02 Jul '10

Another couple of reflexions (sorry for monopolizing): 1. Since i am making a Nomic game, players will have to submit rules. These rules will be written in a sub-set of haskell. Instead of writing my own reader/interpreter, i'd like to use GHC to compil them on the fly, and then add them to the current "legislation". What would you suggest me to do that? Any pointers? 2. For now, the game is more or less playable in GHCi. But my concern is: When you use GHCi, you are in the IO monad, right? How to had state to this monad? I would like that the player can compose his rule in GHCi, and when he is done, he can submit it in GHCi with something like: *Nomic> submitRule <myrule> And then the game takes the rule, possibly modify the current legislation, and give the hand back to GHCi. So the "current legislation" has to be a state of the GHCi's loop. Is this possible at all? submitRule would have a type more or less like that (GameState contains the legislation): submitRule :: Rule -> StateT GameState IO () Thanks for your attention! I know this is a bit confused! Best, Corentin

7 7

State of the Hackage: Q1, Q2 2010
by Don Stewart 01 Jul '10

01 Jul '10

Downloads and popular packages on Hackage for Q1 and Q2 this year. http://donsbot.wordpress.com/2010/06/30/popular-haskell-packages-q2-2010-re… -- Don

4 5

Type-Level Programming
by Walt Rorie-Baety 01 Jul '10

01 Jul '10

I've noticed over the - okay, over the months - that some folks enjoy the puzzle-like qualities of programming in the type system (poor Oleg, he's become #haskell's answer to the "Chuck Norris" meme commonly encountered in MMORPGs). Anyway,... are there any languages out there whose term-level programming resembles Haskell type-level programming, and if so, would a deliberate effort to appeal to that resemblance be an advantage (leaving out for now the hair-pulling effort that such a change would entail)? Or, better yet, is there an Interest Group or committee (Working, or not), that is looking at a coherent architecture or design for a possible future version of Haskell (no offense to Tim Sheard's excelent Ωmega project)? Walt "BMeph" Rorie-Baety "A mountain that eats people? I want one!." - Richard, of LFGComic.com

15 37

Inferring the most general type
by Job Vranish 01 Jul '10

01 Jul '10

Esteemed fellow haskellers, I recently ran into a very simple real life case where Haskell's rules for inferring the types for mutually recursive definitions resulted in a type that was less general than it could be. It took me a while to realize that the type error I was getting wasn't actually a problem with my code. I understand why Haskell does this (it infers the strongly connected mutually recursive definitions monomorphically), but I think it _could_ infer the more general type even with recursive definitions like this. Here is a simplified example that illustrates the problem: > import Data.Maybe > -- The fixed point datatype > data Y f = Y (f (Y f)) > -- silly dummy function > maybeToInt :: Maybe a -> Int > maybeToInt = length . maybeToList > -- f :: Y Maybe -> Int > f (Y x) = g maybeToInt x > g h x = h $ fmap f x This is the type it wants to infer for g g :: (Maybe Int -> Int) -> Maybe (Y Maybe) -> Int This is the type I think it should have, note you can't force the type with a typesig without -XRelaxedPolyRec g :: (Functor f) => (f Int -> b) -> f (Y Maybe) -> b If I use -XRelaxedPolyRec I can manually specify the more general type, but then I have to convince myself that there isn't a more general type that I'm missing. Are there other known algorithms that yield a more general type? and if so, what was the rational for Haskell keeping the current method? I worked out an alternative algorithm that would give a more general type (perhaps the most general type) but it has factorial complexity and probably wouldn't be good for strongly connected groups with 7 or more members. Even so, I would much rather have the inferred types always be the most general ones and be required to add type signatures for mutually recursive groups with 7 or more members (which probably need to be redesigned anyway) than be always required to manually figure out the more general signatures. What do you think? - Job

2 1