April 2009 - Haskell-Cafe

ANN: level-monad-0.3
by Sebastian Fischer 15 Apr '09

15 Apr '09

I am pleased to announce version 0.3 of the package level-monad. This package implements breadth-first search directly as an instance of MonadPlus (without using an intermediate tree representation). In version 0.3 I have added a MonadPlus instance for iterative deepening inspired by Michael Spivey's paper on "Algebras for combinatorial search"[1]. The package is on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/level-monad Sources are on Github: http://github.com/sebfisch/level-monad Cheers, Sebastian [1]: http://spivey.oriel.ox.ac.uk/mike/search-jfp.pdf

1 0

cabal install vs. profiling
by David F. Place 15 Apr '09

15 Apr '09

Hi, Suppose I have installed a number of libraries and have written a program using them. Now, I want to profile my program. What is the best way to get the profiling versions of the libraries installed? Thanks, David

2 1

GHC including System.Time but not Data.Time?
by John Goerzen 15 Apr '09

15 Apr '09

Hi folks, Apologies in advance because this sounds rantish... So I went to my friendly API reference at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html and noticed that I couldn't find Data.Time there anymore. Though it was still at http://www.haskell.org/ghc/docs/6.10.1/html/libraries/index.html After some checking on IRC, apparently this is on purpose. I find it *incredibly* annoying, and leaves us with the following unfortunate set of circumstances: 1) GHC ships with NO way to do date/time calculations in the preferred way (Data.Time) 2) GHC's docs reference only the obsolete (System.Time) way of doing things, with no reference to the preferred way. 3) I can't tell people to just install GHC and expect them to be able to perform date & time calculations the preferred way. Just about EVERY other language (C, Perl, Java, Python, etc.) come with this as part of the base install. 4) I can't update all my apps to use Data.Time without worrying about Yet Another Dependency. 5) Result: black eye on us. As I saw on IRC: <quicksilver> the system isn't supposed to work out the box. <quicksilver> the haskell platform is supposed to work out of the box. <quicksilver> (shame it doesn't exist) Which is a fine goal, but until then, pretty please don't go dropping Data.Time out of GHC. I understand the goal of removing stuff from GHC, but the practical implications can be rather annoying. -- John

3 4

Ambiguous reified dictionaries
by Martijn van Steenbergen 15 Apr '09

15 Apr '09

Good morning, The [1]GHC user's guide, section 8.4.5 says: "The new feature is that pattern-matching on MkSet (as in the definition of insert) makes available an (Eq a) context. In implementation terms, the MkSet constructor has a hidden field that stores the (Eq a) dictionary that is passed to MkSet; so when pattern-matching that dictionary becomes available for the right-hand side of the match." But what happens if there are several dictionaries available? Consider these three modules: ReifyMonoid.hs: > {-# LANGUAGE GADTs #-} > > module ReifyMonoid where > > import Data.Monoid > > data MonoidInst a where > MkMonoidInst :: Monoid a => MonoidInst a ReifySum.hs: > module ReifySum where > > import ReifyMonoid > import Data.Monoid > > instance Monoid Int where > mempty = 0 > mappend = (+) > > intSum :: MonoidInst Int > intSum = MkMonoidInst ReifyProd.hs: > module ReifyProd where > > import ReifyMonoid > import Data.Monoid > > instance Monoid Int where > mempty = 1 > mappend = (*) > > intProd :: MonoidInst Int > intProd = MkMonoidInst Now a function > emp :: MonoidInst a -> a > emp MkMonoidInst = mempty works as you'd expect: *ReifySum ReifyProd> emp intSum 0 *ReifySum ReifyProd> emp intProd 1 But what about this function? > empAmb :: MonoidInst a -> MonoidInst a -> a > empAmb MkMonoidInst MkMonoidInst = mempty Now there are two dictionaries available. GHC consistently picks the one from the second argument: *ReifySum ReifyProd> empAmb intProd intSum 1 *ReifySum ReifyProd> empAmb intSum intProd 0 My questions are: 1) Shouldn't GHC reject this as being ambiguous? 2) Should class constraints only be available on existentially qualified type variables to prevent this from happening at all? 3) Is it possible to implement the following function? > mkMonoidInst :: a -> (a -> a -> a) -> MonoidInst a > mkMonoidInst mempty mappend = ... Thank you, Martijn. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extension…

5 6

Re: Looking for the fastest Haskell primes algorithm
by Johannes Waldmann 15 Apr '09

15 Apr '09

for the API design, always check others before rolling your own. E.g. the (three) functions with "Prime" in their name from http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html I hope they are there for a reason. While we're at it - do we have modPow? modInverse? And of course check their implementation as well (should be straightforward, but you never know). J.W.

1 0

understanding typeable
by Anatoly Yakovenko 15 Apr '09

15 Apr '09

any idea why this is True data Foo = FooC Int | BarC Int deriving (Data, Typeable, Show) > fromJust $ funResultTy (typeOf FooC) (typeOf (1::Int)) Loading package syb ... linking ... done. ParseG.Foo > typeRepTyCon $ fromJust $ funResultTy (typeOf FooC) (typeOf (1::Int)) ParseG.Foo > let a = typeRepTyCon $ fromJust $ funResultTy (typeOf FooC) (typeOf (1::Int)) > :t a a :: TyCon > typeRepTyCon $ typeOf $ BarC 2 ParseG.Foo > let b = typeRepTyCon $ typeOf $ BarC 2 > a == b True I thought that TyCon can distinguish constructors. it seems no different then a typerep

2 2

error handling (esp. IO/exceptions)
by brian＠lorf.org 14 Apr '09

14 Apr '09

I'm finding it hard to write robust code that isn't really ugly. Suppose I want to write > execute :: FilePath -> [String] -> IO (Either ExecuteError ExitCode) where 'ExecuteError' is a data type representing all the ways 'execute' could fail and that 'execute p args' is supposed to * ensure p exists * get p's permissions * ensure p is readable * ensure p is executable * execute p and return its exit code So 'ExecuteError' would have constructors corresponding to these ways to fail: * could not determine whether p exists * p does not exist * could not get p's permissions * p is not readable * p is not executable * could not execute p for some other reason So if I start to code it, I 'tryJust' 'doesFileExist'. If an exception is thrown, I convert it to Left $AppropriateExecuteError. If not, we know whether p exists. If it doesn't, convert it to Left. Otherwise, 'tryJust' 'getPermissions', etc. It's starting to staircase. I'm needing it to be easier to stop my computation and return specific things when exceptions are thrown or when certain requirements aren't met. Thanks for any help.

5 8

lift in TemplateHaskell?
by Lyle Kopnicky 14 Apr '09

14 Apr '09

Hi folks, I'm having trouble reading the TemplateHaskell docs and trying to do something that seems like it should be simple. In MetaML, there is a 'lift' function which does exactly what I want to do. Here's an example function: let double n = [| 2 * $( litE (integerL n) ) |] This works as intended, but instead of writing "litE (integerL n)" I just want to write "lift n", or something similar. I expect that would involve a type class called something like Liftable that would lift literals using the appropriate functions. Does this exist? Thanks, Lyle

1 1

Re: [Haskell-cafe] Printing list of enum type
by michael rice 14 Apr '09

14 Apr '09

I didn't know that, but there's a lot I don't know about Haskell. It works great. Thanks! Michael --- On Tue, 4/14/09, John Dorsey <haskell(a)colquitt.org> wrote: From: John Dorsey <haskell(a)colquitt.org> Subject: Re: [Haskell-cafe] Printing list of enum type To: "michael rice" <nowgate(a)yahoo.com> Cc: haskell-cafe(a)haskell.org Date: Tuesday, April 14, 2009, 3:33 PM Michael, > What do I need to add to this Color enum type to print a list of them? You can also easily print a list of /all/ of them. Regards, John scratch$ cat color.hs data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black deriving (Show,Enum,Bounded) scratch$ ghci color.hs *Main> [minBound..maxBound] :: [Color] [Red,Blue,Green,Yellow,Orange,Brown,White,Black]

1 0

GHC needs a 64 bit machine to be fast?
by FFT 14 Apr '09

14 Apr '09

Not that this is a very good benchmark, but I compiled the nearly equivalent C and Haskell (1st, recursive version) programs from this blog post: http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-h… There, in both versions, 1e9 iterations take 1.8s. However, in my timing on 32-bit Linux machines, the C version is 5-10 times faster. Does the bitness of the OS make a big difference? Here are my timings on a 3.4GHz Pentium D: C : 4.072s (GCC 4.2.4) Haskell : 22.481s (GHC 6.10.2 and 6.8.2 are about the same here) I used the exact same compiler options as in the blog post. I only added import System import Text.Printf to the Haskell program, which seems to be missing. Suspiciously, "ghc -O2 --make" is almost as fast at 24.438s (6.10.2)

6 12