- Haskell-Cafe - Haskell.org

Maybe off-topic -- Writing contracts or software specifications
by Maurício 15 Apr '09

15 Apr '09

Hi, I'm an engineer, and as a programmer I'm just an amateur. This easied things to me, since I could take decisions about practices based on what made sense to me. But now I need to take responsability for some formal programming tasks, and I don't know which examples to follow. I need, for instance, to write a contract with a programmer we are hiring for a task. But the only example I have of such contracts seemed to me (as I said, an amateur. I may be completely wrong) impractical. It was a 150 pages document with every possible user action and every imaginable allowed consequences. But it would be easier to me write the software than such contract itself. Are there ways already accepted by practice on how to write software contracts? It's a small program to acquire and show data from a device, a one person, two months work. I like the guy we are going to hire, and much to my surprise he sugested using Haskell for the task. But he also do not have experience writing such documents. Thanks, Maurício

9 9

Fast mutable arrays of ByteString?
by Maxime Henrion 15 Apr '09

15 Apr '09

Hello all, I have been rewriting a small utility program of mine from C to Haskell for fun. This tool reads lines from stdin or from files, shuffles them one or more times using the Fisher-Yates algorithm, and outputs the result to stdout. Since this algorithm is based on in-place updates, I've been storing my strings in a mutable array in the ST monad. Since it's holding strings I could not use an unboxed array. The resulting program works fine and seems to run at a decent speed, even though it is much slower than the original C version, slightly more so than I expected. While trying to optimize it using profiling, and playing with the number of shuffling passes, I noticed that this operation was responsible for a significant amount of the runtime, much more so than with the C version. I also noticed that the %GC time was around 56%. In order to do more tests, I wrote another version of this program which keeps the strings in a pure and immutable array, and stores the indices of this array in an unboxed mutable ST array. The shuffling is then done on this indices array instead of the strings array. This version runs much faster and only spends ~21% of its time in the garbage collector, at the cost of consuming more memory for the indices array. I'm attaching both versions of the code to this e-mail, and I'd be curious to hear about any possible improvements to it, and whether the performance of STArray of ByteString I'm observing corresponds to people's expectations. Thanks in advance, Maxime Henrion

1 0

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