- Haskell-Cafe - Haskell.org

The Marriage of Heaven and Hell: Type Classes and Bit-Twiddling
by David F. Place 13 Apr '06

13 Apr '06

Hi: Looking around further for a charming way to count bits, I found a method that is completely inscrutable might be very fast. http://graphics.stanford.edu/~seander/bithacks.html Counting bits set in 12, 24, or 32-bit words using 64-bit instructions I thought it would be neat to have size function constrained to members of Bounded that would automatically choose which method depending on the extent of the domain of the set. So, a small set could be computed by the very fast method and the compiler would be able to do the dispatch as part of constant folding. This is what I came up with. It works, but it seems kind of forced. I wonder if there is a better way. sizeB :: (Bounded a,Enum a) => a -> Set a -> Int sizeB e = case fromEnum $ maxBound `asTypeOf` e of x | x <= 12 -> \(Set w) -> fromIntegral $ c12 $ fromIntegral w x | x <= 24 -> \(Set w) -> fromIntegral $ c24 $ fromIntegral w x | x <= 32 -> \(Set w) -> fromIntegral $ c32 $ fromIntegral w _ -> \(Set w) -> bitcount 0 w c12 :: Word64 -> Word64 c12 v = (v * 0x1001001001001 .&. 0x84210842108421) `rem` 0x1f c24' :: Word64 -> Word64 c24' v = ((v .&. 0xfff) * 0x1001001001001 .&. 0x84210842108421) `rem` 0x1f c24 :: Word64 -> Word64 c24 v = (c24' v) + ((((v .&. 0xfff000) `shiftR` 12) * 0x1001001001001 .&. 0x84210842108421) `rem` 0x1f) c32 :: Word64 -> Word64 c32 v = (c24 v) + (((v `shiftR` 24) * 0x1001001001001 .&. 0x84210842108421) `rem` 0x1f) For example: data Test1 = Foo | Bar | Baaz | Quux deriving (Enum, Bounded) sizeTest1 :: (Set Test1) -> Int sizeTest1 = sizeB Foo Cheers, David -------------------------------- David F. Place mailto:d@vidplace.com

1 1

Re: coherence when overlapping?
by oleg＠pobox.com 13 Apr '06

13 Apr '06

It seems that the subject is a bit more complex, and one can force GHC to choose the less specific instance (if one confuses GHC well enough): see the example below. First of all, the inequality constraint is already achievable in Haskell now: "TypeEq t1 t2 False" is such a constraint. One can write polymorphic functions that distinguish if the argument a list (any list of something) or not, etc. One can write stronger invariants like records where labels are guaranteed to be unique. There are two problems: first there are several notions of type inequality, all of which are useful in different circumstances. http://www.haskell.org/pipermail/haskell-prime/2006-March/000936.html Second, how inequality interacts with functional dependencies -- and in general, with the type improvement. And here, many interesting things emerge. For example, the following code > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > {-# OPTIONS -fallow-overlapping-instances #-} > > module Foo1 where > > class C a b | a -> b where > f :: a -> b > > instance C Int Bool where > f x = True > > instance TypeCast Int b => C a b where > f x = typeCast (100::Int) > > class TypeCast a b | a -> b, b->a where typeCast :: a -> b > class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b > class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b > instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () x > instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast'' > instance TypeCast'' () a a where typeCast'' _ x = x > > class D a b | a -> b where > g :: a -> b > > instance D Bool Bool where > g x = not x > > instance TypeCast a b => D a b where > g x = typeCast x > > test1 = f (42::Int) -- ==> True > test2 = f 'a' -- ==> 100 > > test3 = g (1::Int) -- ==> 1 > test4 = g True -- ==> False > > bar x = g (f x) `asTypeOf` x We see that test1 through test4 behave as expected. We can even define the function 'bar'. It's inferred type is *Foo1> :t bar bar :: (C a b, D b a) => a -> a The question becomes: is this a function? Can it be applied to anything at all? If we apply it to Int (thus instantiating the type a to Int), the type b is instantiated to Bool, and so (following the functional dependency for class D), the type a should be Bool (and it is already an Int). OTH, if we apply bar to anything but Int, then the type b should be Int, and so should the type a. Liar's paradox. And indeed, bar cannot be applied to anything because the constraints are contradictory. What is more interesting is the slight variation of that example: > class C a b | a -> b where > f :: a -> b > > instance C Int Int where > f x = 10+x > > instance TypeCast a b => C a b where > f x = typeCast x > > class D a b | a -> b where > g :: a -> b > > instance D Int Bool where > g x = True > > instance TypeCast Int b => D a b where > g x = typeCast (10::Int) > > test1 = f (42::Int) > test2 = f 'a' > > test3 = g (1::Int) > test4 = g True > > bar x = g (f x) `asTypeOf` x > > test5 = bar (1::Int) *Foo> :t bar bar :: (C a b, D b a) => a -> a If bar is applied to an Int, then the type b should be an Int, so the first instance of D ought to have been chosen, which gives the contradiction a = Bool. And yet it works (GHC 6.4.1). Test5 is accepted and even works *Foo> test5 10

2 1

coherence when overlapping?
by william kim 13 Apr '06

13 Apr '06

Hi All, One important property of type class dictionary translation is coherence which basically says that two typing derivations for the same term at the same type in the same environment must be equivalent. This definition is established with the assumption of non-overlapping. In the GHC documentation which describes the extension of overlapping instances, an example similar to the following is given. >class C a where > f:a -> a >instance C Int where > f=e1 >instance C a where > f=e2 > >let g x = f x >in g 1 In this case GHC takes an ¡°incoherent¡± decision by taking the second instance as an instantiation of function f even it is executed with an input of type Int. My question is whether the ¡°incoherence¡± behaviour of overlapping instances is derived from the definition of coherence in the non-overlapping setting? If yes, how is it applicable to rule out the incoherent behaviour? If otherwise, what is the definition of coherence with overlapping instances? Thanks. --william _________________________________________________________________ Find just what you are after with the more precise, more powerful new MSN Search. http://search.msn.com.sg/ Try it now.

2 2

Fundeps: I feel dumb
by Creighton Hogg 13 Apr '06

13 Apr '06

Hi, So I'm trying the fun-deps example from http://www.haskell.org/hawiki/FunDeps and seeing if I can use it, but I can't really get things to work the way I want. The code follows below, and the error I get if I try to multiply 10 <*> (vector 10 [0..9]) is No instance for (MatrixProduct a (Vec b) c) arising from use of `<*>' at <interactive>:1:3-5 Probable fix: add an instance declaration for (MatrixProduct a (Vec b) c) In the definition of `it': it = 10 <*> (vector 10 ([0 .. 9])) import Array -- The elements and the size data Vec a = Vec (Array Int a) Int deriving (Show,Eq) type Matrix a = (Vec (Vec a)) class MatrixProduct a b c | a b -> c where (<*>) :: a -> b -> c instance (Num a) => MatrixProduct a (Vec a) (Vec a) where (<*>) num (Vec a s) = Vec (fmap (*num) a) s vector n elms = Vec (array (0,n-1) $ zip [0..n-1] elms) n

1 0

Announcing Halfs, a Haskell Filesystem
by Isaac Jones 12 Apr '06

12 Apr '06

Halfs is a filesystem implemented in the functional programming language Haskell. Halfs can be mounted and used like any other Linux filesystem, or used as a library. Halfs is a fork (and a port) of the filesystem developed by Galois Connections. We've created a virtual machine to make using Halfs extremely easy. You don't need an extra partition or a thumb drive, or even Linux (Windows and Mac OS can emulate the virtual machine). For the impatient, go to the quick start: http://hackage.haskell.org/trac/halfs/wiki/QuickStart The Halfs web page is here: http://www.haskell.org/halfs/ Background: In the course of developing a web server for an embedded operating system, Galois Connections had need of a filesystem which was small enough to alter to our needs and written in a high-level language so that we could show certain high assurance properties about its behavior. Since we had already ported the Haskell runtime to this operating system, Haskell was the obvious language of choice. Halfs is a port of our filesystem to Linux, with some modifications. High assurance development is a methodology for creating software systems that meet rigorously-defined specifications with a high degree of confidence. That methodology comprises tools and practices. Its goal is to produce such systems reliably and effectively, with an ordinary degree of developer effort. Haskell is particularly well-suited to high assurance development. It is a high-level, fully-expressive, pure, functional language, with a powerful type system. One of the obligations of high assurance development is the demonstration of strong correspondence between high-level executable models and the eventual implementation. Haskell supports this directly: it can describe systems all the way from high-level executable models through to system implementations. The fact that Haskell is pure comes from its mathematical basis, and means that, by default, a function does not interfere with other functions. The type system is an automatic and scalable proof engine that can encode and enforce desirable properties. Together, these features allow the correctness of complex systems to be established, making Haskell ideal for high assurance development. The question was whether Haskell is well suited as the implementation language for a filesystem, which involves fixed sized buffers, lots of IO, and binary data structures. Though correctness is much more important to us than performance, we hoped that a Haskell filesystem would have acceptable performance, and that writing such low-level code would not be awkward or error-prone. We have developed a filesystem, Halfs, which aims to answer the above questions. One may mount a Halfs filesystem in Linux using the FUSE (Filesystem in Userspace) kernel module. We have created two new monads, FSRead and FSWrite which restrict the IO monad to reading and writing operations respectively. For performance, Halfs uses efficient mutable arrays for block IO, as well as caching for blocks and inodes.

1 0

Ambiguous types for collection keys
by Scott Weeks 12 Apr '06

12 Apr '06

Hello everyone, I've been banging my head against my desk a bit so I figured it's time to ask for help :-) I'm writing an application that persists data to disk. The hard stuff is pretty much done (binary serialisation, etc...) The big stumbling block is that I want users to be able to define their own schemas. This means that the keys for a data store may be Integer, Strings, etc... I have a BTreeIndex type: data BTreeIndex a b = Branch { parentBT :: !BlockPtr, keysBT :: ![a], kidsBT :: ![BlockPtr] } | Leaf { parentBT :: !BlockPtr, valsBT :: !(LeafMap a b), prevBT :: !PrevLeaf, nextBT :: !NextLeaf } type IdxPS = BTreeIndex PackedString BlockPtr type IdxInt = BTreeIndex Integer BlockPtr When a user queries I have to read the input from IO and then somehow cast the key/index type without angering the type checker. If I omit the following function I get the ominous "Ambiguous type variable a..." error. If I use it I get a complaint that the checker was expecting an Integer rather than a PackedString. coerceIndex f (Schema _ SInt SPtr _) (r,hdl,o,hdr) = f (r::IdxInt,hdl,o,hdr) coerceIndex f (Schema _ SStr SPtr _) (r,hdl,o,hdr) = f (r::IdxPS,hdl,o,hdr) Where f is a curried select function (e.g. selectAll, selectByKey, etc...) waiting for the final tuple containing the index and other miscellanea that is needed to read the data. I'm hopelessly lost and I assume that the many brilliant minds on this list will chuckle, pat me on the head and tell me what I've been doing wrong. Thanks for your time guys, Scott

4 7

accurately scheduling events
by Henning Thielemann 11 Apr '06

11 Apr '06

I try to schedule musical events and this shall happen quite accurately. I found 'usleep' which is limited to Posix and I cannot interrupt with Ctrl-C if IO actions are scheduled using this function. Then I found 'threadDelay' which can be interrupted, but it is stated that its resolution is 1/50 seconds, which is too coarse. Additionally I found that it liberally rounds the waiting time up to the next multiple of 1/50 second. Even 'threadDelay 0' waits some time. This might be due to the fact that threadDelay was not intended for such applications, but it shall wait at least the time specified: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-January/006148.… My question: Is there some more accurate time scheduling available? Maybe not only a more accurate 'wait' function but a function which processes a list of events and starts the actions at the appropriate time points. When I write do action0 threadDelay t action1 then action1 is not started duration t after action0 is started, but time t after action0 is finished. This should be avoided by a sophisticated scheduling function. This is how I currently employ threadDelay: http://cvs.haskell.org/darcs/haskore/src/Haskore/Basic/Schedule.lhs

3 3

Re: [Haskell-cafe] web servers
by Tim Newsham 11 Apr '06

11 Apr '06

> There's this link: http://www.mdstud.chalmers.se/~md9ms/hws-wp/ Yes there is, but its a broken link. I tried mailing the author and got no response. > From memory I think there may have been a more recent version at > scannedinavian.org (possibly only accessible with darcs?), but still a couple > of years with no apparent activity. I'll try to get it from here. Thanks. > If anyone is interested in using it, contributing to it, or picking over > it for use in an existing project, I'll try and find somewhere stable to > host it and change the licence. Feel free to ask questions on what it > does/doesn't do. You'll probably need to, given the documentation ;-) I'd be interested in looking at it, at the least. > Regardless of it's utility, any criticism or advice on the code would be > appreciated. I'm a bit of a haskell noob, so don't expect anything brilliant. > Daniel Tim Newsham http://www.lava.net/~newsham/

1 0

Substitute for records?
by Mattias Bengtsson 10 Apr '06

10 Apr '06

Currently i'm working, together with a friend, on an abstraction (sort of) of HaskellDB for a school-project. Basically we are generating haskell-modules similar to those generated by DBDirect in HaskellDB together with some helpers for the most common queries you'd want to run. HaskellDB has its own record system (HDBRec) and a HaskellDB-query also returns such a record. The accessor-functions for these records can later be found in DatabaseName.TableName.ColumnName.column. These should be imported qualified to avoid name clashes. This is some example code: students <- School.Students.all db mapM_ printStudentId students printStudentId rec = print $ rec!School.Students.Id.column The main problem for me here is this part: rec!School.Students.Name.column where i would rather just write rec!id This isn't possible and the other way is just too messy for my taste. It simply isn't the easy and nice syntax i had hoped for when we started to develop this. Are there any other nice substitutes for HDBRec or normal haskell records that i could use that doesn't make name clashes an issue? Mattias

2 1

Understanding allocation behavior
by David F. Place 10 Apr '06

10 Apr '06

After reading Daniel Fischer's message about trying to use EnumSet in his Sudoku.hs and finding that it was slower when processing a large data set, I decided to do some profiling. I rewrote his solver to use EnumSets and profiled it. The culprit turns out to be the following function which is responsible for 22% of the allocating in the run. Is there a more efficient way to write this function? foldBits :: Bits c => (a -> Int -> a) -> a -> c -> a foldbits _ z 0 = z foldBits f z bs = foldBits' f 0 bs z foldBits' :: Bits c => (a -> Int -> a) -> Int -> c -> a -> a foldBits' f i bs z | bs == 0 = z | otherwise = z' `seq` foldBits' f i' bs' z' where z' | 1 == bs .&. 1 = f z i | otherwise = z i' = i + 1 bs' = bs `shiftR` 1 ps. I was impressed with how hairy DF's algorithm is and I am not really enough interested in Sudoku to spend the time needed to grok it. So, I decided to try an experiment to see if I could restructure it without understanding it very deeply. Step 1. comment out all the type signatures. Step 2. find the main place that I wanted to change from [Int] to (Set Int) Step 3. compile; make obvious edits; repeat until 0 errors I had it running in a few minutes. I can't imagine doing that in any other programming environment! Cheers, David -------------------------------- David F. Place mailto:d@vidplace.com

4 12

lambda evaluator in GADT
by paul＠theV.net 10 Apr '06

10 Apr '06

The introduction to GADT usually starts with a little expression evaluator. So I gave it a try, but there are some troubles. A little data type for lambda expression > data E a where > Lit :: a -> E a > App :: E (a -> b) -> E a -> E b > Lam :: Var a -> E b -> E (a -> b) > Val :: Var a -> E a > > data Var a = Var String some sample values > e1 = Lit 1 > plus = Lit (\x y -> x + y) Next, plus' demonstrate a pitfall in my data definition, i.e., the variable introduced by Lam has type forall a . a, which is is too general force a constraint on its occurrances. I wonder if there a way to make it work. > plus' = let v1 = Var "x" > v2 = Var "y" > in Lam v1 (Lam v2 (App (App plus (Val v1)) (Val v2))) evaluation > eval :: E a -> a > eval (Lit x) = x > eval (App f x) = (eval f) (eval x) > eval (Lam (Var v) e) = \x -> eval (sub v (Lit x) e) > eval (Val (Var v)) = undefined substituation > sub :: String -> E b -> E c -> E c > sub v e e1@(Lit x) = e1 > sub v e (App f x) = App (sub v e f) (sub v e x) > sub v e e'@(Lam w'@(Var w) x) = > if v == w then e' > else Lam w' (sub v e x) the above all works fine, except for the following > {-- > sub v e e'@(Val (Var w)) = > if v == w then e > else e' > --} It seems the last case requires a unification of b and c, which is simply too strong for other cases. What should I do here? Instead of substituting on term level, an alternative way to implement eval is to use an environment to map variables to its values, but that requires all expression values to have a uniform type, which is a conflict to GADT. I'm sure this could be a common issue encountered by GADT beginners, how does one get around it? One solution on top of my head is to use a sum type (or even type class) and stuff every possible value types under it, but that defeats the purpose of using GADT in the first place. Any help is greatly appreciated! Regards, Paul Liu

2 1

Chapter 4 of Hitchhikers Guide to the Haskell is out
by Dmitry Astapov 09 Apr '06

09 Apr '06

Hello, After great amount of procrastination I finally put online the next installment of my Haskell tutorial, which could be found at http://www.haskell.org/haskellwiki/Hitchhikers_Guide_to_the_Haskell Many thanks to all who commented on my efforst, spell-checked the text and urged me to go forward. As alway I'm interested in any feedback. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

1 0

Rank 2 polymorphism in pattern matching?
by C Rodrigues 08 Apr '06

08 Apr '06

This counterintuitive typechecking result came up when I wrote a wrapper around runST. Is there some limitation of HM with respect to type checking pattern matching? data X a b = X (a -> a) run :: forall a. (forall b. X a b) -> a -> a -- This definition doesn't pass the typechecker run (X f) = f -- But this definition works run x = (\(X f) -> f) x

3 2

Positive integers
by Daniel McAllansmith 08 Apr '06

08 Apr '06

Unless I've missed it, there is no typeclass for positive integers in GHC. Is there any particular reason it doesn't exist? Also, it seems Word would be a far better type in the likes of (!!), length, etc. Is it just tradition that resulted in the use of Int? Daniel

16 30

Re: [Haskell] reading binary files
by Dmitry V'yal 07 Apr '06

07 Apr '06

Hello, Bulat I'm currently working on some kind of program for analysing FAT partitions. Don't ask why did I chose to implement it in Haskell :) Just for fun. My program needs to read scattered chunks of binary data from a huge file and to do a good amount of deserialisation. I implemented basic functionality using Handles and Ptr's and now I'm starting to regret for it. I have some pieces of code like: type PtrAdvancer a b = StateT (Ptr a) IO b peek_one :: Storable b => PtrAdvancer a b peek_one = do p <- get res <- lift $ peek $ castPtr p put $ plusPtr p $ sizeOf res return res peek_many :: Storable b => Int -> PtrAdvancer a [b] peek_many 0 = return [] peek_many n = do first <- peek_one rest <- peek_many $ n-1 return $ first:rest data DirEntry = DirEntry { name :: String, attr :: Word8, crt_time_tenth :: Word8, crt_time :: Word16, crt_data :: Word16, lst_acc_data :: Word16, wrt_time :: Word16, wrt_date :: Word16, fst_cluster :: Word32, file_size :: Word32 } deriving Show instance Storable DirEntry where sizeOf _ = 32 alignment _ = 32 peek = evalStateT peek_dir_entry peek_dir_entry = do n <- peek_many 11 :: PtrAdvancer a [Word8] at <- peek_one peek_one :: PtrAdvancer a Word8 ctt <- peek_one ct <- peek_one cd <- peek_one lad <- peek_one fch <- peek_one :: PtrAdvancer a Word16 wt <- peek_one wd <- peek_one fcl <- peek_one :: PtrAdvancer a Word16 fs <- peek_one return $ DirEntry (words_to_str n) at ctt ct cd lad wt wd ((fromIntegral fch `shiftL` 16) + fromIntegral fcl) fs or: read_cluster_chain32 :: Handle -> FatAddress -> Cluster -> IO [Cluster] read_cluster_chain32 h start cluster = do allocaBytes 4 $ \p -> chain32' p cluster True where chain32' p c need_seek = do when need_seek $ hSeek h AbsoluteSeek (fromIntegral $ start + c * 4) hGetBuf h p 4 val <- peek p :: IO Word32 let val28 = val .&. 0x0fffffff case val28 of 0x0 -> return [] 0x0fffffff -> return [c] otherwise -> do rest <- if c+1 == val28 then chain32' p val28 False else chain32' p val28 True return $ c:rest It works with a mediocre speed (about 10Mb/s when extracting files), but design is ugly IMO. For example I need to write twice as much number of lines of marshalling code compared to C. For data type declaration and then for Storable instance. Is there a way to avoid it? > > with my lib, you can either read data directly from file (through > implicit 512-byte buffer) or read whole file into the automatically > allocated buffer with `readFromFile`. what is better - depends on what > you plan to do with rest of file > Now I'm going to rewrite my code to make use of io library. So my question is whether your library is well suited for such application (frequent positioning and reading small pieces of data).

3 2

EnumSet with a BSD license
by David F. Place 06 Apr '06

06 Apr '06

Hi All, Since there is some interest in my EnumSet module, I am reposting it here with a BSD license in anticipation of its rebirth as Data.Set.Enum. Cheers, David -------------------------------- David F. Place mailto:d@vidplace.com

2 2

Re: [Haskell] What's up with this Haskell runtime error message:
by Michael Goodrich 06 Apr '06

06 Apr '06

Thanks so much for your help. I should have made clear that I was aware that the definitions were mutually dependent. What I was hoping was that Haskell could solve this for me without my having to resort to effectively finessing any sequencing considerations. Perhaps I am really asking it to do too much. This I thought might be reasonable since one is supposed to be achieving a sequence-less style of programming. But this would seem to be a counter example where I will be essentially forced to implement a sequential processing semantic in a language environment which ostensibly would deny me such (for my own good I understand). Thoughts? On 4/6/06, Garrett Mitchener <garrett.mitchener(a)gmail.com> wrote: > > I came up with a system of coloring -- you'll have to view this message as > html to see it. You start with the input parameters -- those are green. > Anything defined in terms of green is blue. Anything defined in terms of > green & blue is purple. Anything defined in terms of green, blue, and > purple is orange, etc. Then you can see the problem. So in foo, everything > checks out, you get to orange and there's just a couple of expressions left > and you can see that there's no loop. > > > ----------------------------------------------------------------------------------------------------------- > > > > > > foo (step,r0,mu0) = bar ( > > step,r1,r0,mu1,mu0) > > where > > r1 = r0- > > step*rd > > mu1 = mu0-step*mud > > > > rd = c*c*mu0 > > mud > > = c*c/r0 - (foobar_r z)/c > > > > c = baz(z) > > z = 6.378388e6-r0 > > > > baz z | z<125 = -0.25*z+1537.5 > > > > | otherwise = 0.0169*z+1504.1 > > > > foobar_r z | z<125 = 0.25 > > > > | otherwise = -0.0169 > > > > > But when you try coloring bar, you get this far and then we're stuck. The > problem is clear: r depends on rdc, which depends on rd0, which depends on > c0, which depends on z0, which depends on r. So your definition for r > includes a loop. > > bar > > (step,r2,r1,mu2,mu1) = (r,z0) : bar (step,r1,r,mu1,m) > > where > > r = r2 > > +2*step*rdc > > m = mu2+2*step*mudc > > rdc = ( > > rd2+rd1+rd0)/6 > > mudc = (mud2+mud1+mud0)/6 > > > > > > rd2 = c2*c2*mu2 > > mud2 > > = c2*c2/r2 - (foobar_r z2)/c2 > > > > > > rd1 = c1*c1*mu1 > > mud1 = > > c1*c1/r1 - (foobar_r z1)/c1 > > > > rd0 = c0*c0*m > > mud0 = c0*c0/r - (foobar_r z0)/c0 > > > > > > c2 = baz(z2) > > > > c1 = baz( > > z1) > > c0 = baz(z0) > > > > z2 = 6.378388e6-r2 > > z1 = 6.378388e6 > > -r1 > > z0 = 6.378388e6-r > > > > main :: IO () > > main = do > > print $ take 100 (foo (0.1, 6.378388e6,0)) > > > > > > > > > > > > >

4 4

Re: [Haskell] What's up with this Haskell runtime error message:
by Michael Goodrich 06 Apr '06

06 Apr '06

Looks like my calulation involves a self referential set of definitions. Is Haskell not able to deal with a self referential set of definitions? I was frankly hoing it would since otherwise there is then the specter of sequence, i.e. that I have to finesse the order in which things are calculated so as to avoid it. Thoughts? cheers, -Mike

5 8

"show" for functional types
by Greg Buchholz 05 Apr '06

05 Apr '06

In section 5 of _Fun with Phantom Types_, Hinze states... "Let us move on to one of the miracles of theoretical computer science. In Haskell, one cannot show values of functional types. For reasons of computability, there is no systematic way of showing functions and any ad-hoc approach would destroy referential transparency (except if show were a constant function). For instance, if show yielded the text of a function definition, we could distinguish, say, quick sort from merge sort. Substituting one for the other could then possibly change the meaning of a program." ...I guess I'm not understanding what that means. Would there be some sort of contradiction that arises when trying to evaluate "show (show)" or somesuch? Can anyone point me in the direction of information that tries to explain why this is? I'm at a loss as to what search terms to use. Thanks, Greg Buchholz

11 31

Re: [Haskell] reading binary files
by Benjamin Franksen 05 Apr '06

05 Apr '06

[questions such as this one should go to cafe] On Wednesday 05 April 2006 20:41, minh thu wrote: > 1/ i want to read some binary file (e.g. targa file format : *.tga). > > -- first way : via IOUArray > showInfoHeader1 handle = do > a <- newArray_ (1,8) :: IO (IOUArray Int Word8) > hGetArray handle a 8 > idLength <- readArray a 1 -- or getElems... > putStrLn ("id length : " ++ show idLength) > return () > > -- second way : via c-like array > showInfoHeader2 handle = do > b <- mallocArray 8 :: IO (Ptr Word8) > hGetBuf handle b 8 > [idLength] <- peekArray 1 b -- or peakArray 8 b The index should be 0 if you want to read the first byte. Also, if you are only interested in the first byte, you could simply idLength <- peek b or if it is not the first byte, then idLength <- peekByteOff b i However, it is better to use arrays, than pointers. > putStrLn ("id length : " ++ show idLength) > free b > return () > > so, briefly, i have to read some content into some kind of buffer > (IOUArray Int Word8 or Ptr Word8), then get one (or more) elements > from the buffor into a standard haskell variable (is it the correct > word ?) (or list). > > in the second case, i also have to free the buffer. Or use alloca or allocaBytes, which are both a lot faster than malloc and free. > in some case, when the data is more than one Word8 long, i have to > 'reconstruct' it, i.e.: > > [x1,x2] <- getElems a This will give you a run-time error, because you array is 8 elements long, not 2. You can do x1:x2:_ <- ... or better still x1 <- readArray b 1 x2 <- readArray b 2 Still better: Use one of the available binary serialisation libraries. They are already tuned for efficiency and give you a much nicer high-level API. > let x = fromIntegral x1 + fromIntegral x2 * 256 :: Int > > is it the correct way to read binary files ? Depends on the byte order that is used in your file format. If it is big-endian then correct, else not correct. (I hope I did get this right; I always tend to confuse big- and little-endian.) > 2/ haskell is (i heard that once ... :-) a high level language, so it > has (must have) good support for abstraction... Sure. See abve mentioned libraries. > but in 1/, i have to choose between different kind of array > representation (and i dont know which one is better) and it seems to > me that the resulting code (compiled) would have to be the same. I strongly recommend using some Array type (IOU or whatever). Ptr is really just a raw pointer into memory: no protection from out-of-bounds access, etc. much like in C. Ptr has been invented for interfacing with C routines, not for regular Haskell programming. HTH, Ben

1 0

Re: [Haskell] What's up with this Haskell runtime error message:
by Jon Fairbairn 05 Apr '06

05 Apr '06

On 2006-04-05 at 14:03EDT "Michael Goodrich" wrote: > BTW, I can't seem to locate 'haskell-cafe'. http://www.haskell.org/mailman/listinfo/haskell-cafe > The message responding to my sign-up said nothing about > haskell-cafe. Perhaps it should. It's so long since I signed up to haskell that I've forgotten what the sign-up message says. > Also, in my infinte-looping application, I am wrapping the > calculation in a 'take 1000' function - shouldn't this > guarantee termination? Not on its own loop = loop:: Char l = [1,2,3,loop,5,6] putStr $ show $ take 4 l will print 1 2 and 3 and then loop when trying to find the value for the fourth. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

1 0

Re: [Haskell] What's up with this Haskell runtime error message:
by Jon Fairbairn 05 Apr '06

05 Apr '06

On 2006-04-05 at 12:35EDT "Michael Goodrich" wrote: > Greetings All: > > GHC gives: Fail: <<loop>> > > Hugs gives: [(ERROR - C stack overflow Nowt's up wi' ' runtime error message. GHC's perfectly lucid. It says your programme went into an infinite loop. This sort of thing belongs on haskell-cafe, by the way. I've moved it there. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

1 0

PPM image manipulation
by newb 05 Apr '06

05 Apr '06

having some trouble trying to be able to manipulate PPM images. I want to be able to desaturate and also double the scale of them. im a first time user of haskell so am not very familiar with it. any info would be great! thanks! -- View this message in context: http://www.nabble.com/PPM-image-manipulation-t1382306.html#a3711988 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.

3 3

RE: generics question 2
by Ralf Lammel 05 Apr '06

05 Apr '06

Hi Frederik, [resending; as it bounced because of size.] That’s a tricky one. Let’s first recall that this one is still fine: *Main> :t cast True :: (Typeable a, Typeable b) => Maybe (a,b) cast True :: (Typeable a, Typeable b) => Maybe (a,b) :: (Typeable b, Typeable a) => Maybe (a, b) The type error for your attempt was caused by the attempt to print this polymorphic maybe. The overloading resolution for the show instance cannot possibly deal with this polymorphism. More generally, any dependent SYB functionality or class-based code would run into this problem. However, the above polymorphic cast, as such does not work as you would expect. Here is a clear example: sigh = maybe 0 (\(a,b) -> gsize a + gsize b) (cast True) The component types of this product are *ambiguous*. Cast is monomorphic. No way to use it for polymorphic problems. So we need polymorphic type extension, here: dataCast2 provided by the Data class. So here is how it works with polymorphic type extension. See below and check out the 2nd paper for some deeper discussion. Or if you find this all too complicated, use class-based SYB style (3rd SYB paper). Thanks for keeping me off the street. ☺ Regards, Ralf import Data.Generics -- -- A weird gsize function -- g :: Data a => a -> Int g = gsize `extQ` (\(x::Int) -> x) `ext2Q` f where f :: (Data a, Data b) => (a,b) -> Int f (a,b) = g a + g b + 1 -- -- | Flexible type extension -- Should be in Data.Generics.Aliases -- ext2 :: (Data a, Typeable2 t) => c a -> (forall a b. (Data a, Data b) => c (t a b)) -> c a ext2 def ext = maybe def id (dataCast2 ext) -- -- | Type extension of transformations for unary type constructors -- Should be in Data.Generics.Aliases -- ext2T :: (Data d, Typeable2 t) => (forall d. Data d => d -> d) -> (forall d d'. (Data d, Data d') => t d d' -> t d d') -> d -> d ext2T def ext = unT ((T def) `ext2` (T ext)) -- -- | Type extension of queries for type constructors -- Should be in Data.Generics.Aliases -- ext2Q :: (Data d, Typeable2 t) => (d -> q) -> (forall d d'. (Data d, Data d') => t d d' -> q) -> d -> q ext2Q def ext = unQ ((Q def) `ext2` (Q ext)) -- -- | The type constructor for transformations -- Not exported from Data.Generics.Aliases -- newtype T x = T { unT :: x -> x } -- -- | The type constructor for queries -- Not exported from Data.Generics.Aliases -- newtype Q q x = Q { unQ :: x -> q } -- -- Time to test -- data Foo = Foo1 Int | Foo2 (Int,Int) deriving (Typeable, Data, Show) main = do print $ gmapQ g (Foo1 88) print $ gmapQ g (Foo2 (21,20)) > -----Original Message----- > From: Frederik Eaton [mailto:frederik@a5.repetae.net] > > What I want to do is specialise not to a specific type like Bool but > to the class of all pairs (a,b). But this causes the compiler to > complain, even for simpler examples: > > cast True :: (Typeable a, Typeable b) => Maybe (a,b) > > <interactive>:1:0: > Ambiguous type variable `a' in the constraints: > `Typeable a' arising from instantiating a type signature at > <interactive>:1:0-51 > `Show a' arising from use of `print' at Top level > Probable fix: add a type signature that fixes these type variable(s) > > <interactive>:1:0: > Ambiguous type variable `b' in the constraints: > `Typeable b' arising from instantiating a type signature at > <interactive>:1:0-51 > `Show b' arising from use of `print' at Top level > Probable fix: add a type signature that fixes these type variable(s) > > Is there a way to solve this, or do I have to avoid polymorphism? I > can use 'toConstr' to find out dynamically if a particular type is a > pair, and then use unsafeCoerce, but I hear that unsafeCoerce is > unsafe.

1 0

RE: generics question 2
by Ralf Lammel 04 Apr '06

04 Apr '06

> Hi Ralf, > > I'm looking for a function like extT but with more general type: > > (t a -> s a) -> (t b -> s b) -> (t a -> s a) > > Is there such a thing in the generics library? Hi Frederik, Not sure how you are exactly going to use such an operation ... But here is its implementation anyhow. Thanks for the riddle. Ralf import Data.Generics -- Frederik's weird ext operation :-) ext' :: (Data (t a), Data (s a), Data (t b), Data (s b)) => (t a -> s a) -> (t b -> s b) -> (t a -> s a) ext' f g ta = case cast g of Just g' -> g' ta Nothing -> f ta -- A generic default f (Just x) = [x] f Nothing = [] -- A type-specific case g (Just True) = [True] g (Just False) = [] g Nothing = [] -- A composition using our new type-extension operator test :: Data a => Maybe a -> [a] test = ext' f g -- Let's see whether it works ... main = do print $ test (Just (1::Int)) print $ test (Just False)

2 1

Creating a profiling version of FPS
by Jeremy O'Donoghue 04 Apr '06

04 Apr '06

Hi list, I'm currently working on a pretty simple Haskell program to manipulate memory dumps taken from an embedded environment. The memory dumps are 64MB in length, so I manipulate them using Don Stuart's Fast Packed String library, as it supports mmapped files. I'm a relative Haskell newbie, so unsurprisingly my first attempt has dreadful performance (30% of time spent in GC), and I want to do some profiling to find out why. The difficulty is that I seem to be unable to produce a profiling-enabled version of the FPS library, which means that my application cannot be compiled with profiling enabled. I notice that most of the GHC libraries seem to come with both profiling and non-profiling versions enabled. Does anyone know how I can create both profiling and non-profiling version of FPS? As a matter of interest (feature request), why doesn't Cabal build profiling and non-profiling libraries as a matter of course, given that you can't link non-profiling code with profiling-enabled code? Thanks in advance Jeremy

2 1

Re: Indent for haskell
by dons＠cse.unsw.edu.au 04 Apr '06

04 Apr '06

patc: > > Is there an equivalent of an "indent" program for haskell? I have a > bit of code I want to clean up ... You could run your code through ghc, with -ddump-parsed turned on. Then with a little bit of sed magic, you could recover the original code Before: $ cat B.hs main = do { ;print (f 10) ; print (f 20) ;print (f 0xdeadbeef) } f x = sqrt ( fromIntegral (x * 10133123 `mod` 1231111121 :: Int )) After: $ ghc -fno-code -ddump-parsed B.hs ==================== Parser ==================== main = do print (f 10) print (f 20) print (f 3735928559) f x = sqrt (fromIntegral ((x * 10133123) `mod` 1231111121 :: Int)) Postprocess: $ ghc -fno-code -ddump-parsed B.hs | sed '/^===/d' main = do print (f 10) print (f 20) print (f 3735928559) f x = sqrt (fromIntegral ((x * 10133123) `mod` 1231111121 :: Int)) Yay! Now, I suspect there may be actually be (not well publicised) tools for this. If there are, they should go on the haskell.org "Libraries and tools" page. -- Don

1 0

Strafunski
by Christopher Brown 04 Apr '06

04 Apr '06

Hi, I am trying to use Strafunski with GHC 6.5 and was wondering if someone could help me. I have all the instances for Term and Typeable defined for my data types, but when I try to compile with GHC 6.5 I get lots of "overlapping instance" errors. In particular, it seems the instances I am using (generated by DrIFT) are clashing with the ones in Data.Typeable. Is there a way I can fix this? Also I have heard that it is possible to add "deriving Typeable" to each data type and I don't need to use the instances I have created. However, now it complains that it can't find instances for Term - but I can't derive from Term. Does anyone have any ideas how I can get Strafunski working with GHC 6.5? Thanks. Chris. Christopher Brown PhD Student, University of Kent. http://www.cs.kent.ac.uk/people/rpg/cmb21/ cmb21(a)kent.ac.uk

4 6

Efficient Sets for Small Enumerations
by David F. Place 03 Apr '06

03 Apr '06

Often when writing algorithms which involve set operations on small enumerations, I start off using Data.Set. I soon find performance requires rewriting that code to use bitwise operations. I miss the nice interface of Data.Set and the type checking of using a proper data type. So, as an exercise in writing a library, I wrote out an implementation of bitwise set operations using the interface of Data.Set with a couple of extensions. It provides an abstract interface and type checking. Using GHC -O3, code compiles right down to the primitive bit-twiddling operators. My example program (a sudoku solver) runs several times faster. I'll be grateful for any feedback on this. Perhaps something like it would be useful included in the standard libraries. Cheers, David -------------------------------- David F. Place mailto:d@vidplace.com

3 6

Distributing monadic(?) functions across dyadic functions
by tpledger＠ihug.co.nz 03 Apr '06

03 Apr '06

Nils Anders Danielsson wrote: > A function like this has been suggested for the > standard libraries a couple of times before. > Someone suggested the name "on", which I quite > like: > > (*) `on` f = \x y -> f x * f y Thanks! I always wanted to be someone. :-) Here's the link. http://www.haskell.org//pipermail/haskell-cafe/2004-December/007917.html - Tom

1 0

RE: [Haskell-cafe] generics question, logical variables
by Ralf Lammel 03 Apr '06

03 Apr '06

Frederik, > As for your code example, it looks very interesting, but are you > saying that this could turn into an extension of the Data.Generics > library, or that this is something I could be implementing in terms of > what's already there? The posted code works with GHC 6.4 (SYB2) intentionally and actually. I have attached another attempt (again GHC 6.4, based on SYB2) which might be more useful for your purposes, and it may be useful in general, in fact. What I defined this time is a "certainty-improving" function: idify :: (Typeable1 f, Monad m, Data (a f), Data (a Id)) => (forall a. f a -> m a) -> a f -> m (a Id) That is, the function "idify get" takes a value whose type is parameterized in a type constructor f (such as Maybe or IORef), and the function attempts to establish Id instead of f on the basis of the function argument "get". > What is the 'a' parameter for in "force"? > > force :: ( Data (t Maybe a) > , Data (t Id a) > , Term t Maybe a > , Term t Id a > ) => t Maybe a -> t Id a The previous attempt was a more parameterized blow than required in your case. (I was guessing about what "typed logical variables" could mean. I was assuming that you would need some extra layer of embedding types on top of the Haskell term types. Looking at your code, this was not the case.) > For the part which I asked for help with, to get around my trouble > with generics, I defined a class GenFunctor and an example instance. > The intent is that generics should be able to provide this > functionality automatically later on, but you can see what the > functionality is. Let's look at the type of your GenFunctor: class GenFunctor f where gfmapM :: (Monad m, FunctorM b) => (forall x . a x -> m (b x)) -> f a -> m (f b) This type can be seen as a more relaxed version of the idify operation above. That is, idify fixes GenFunctor's b to Id. The particular encoding of idify (attached) takes advantage of this restriction. I wonder whether I should bother. (Exercise for reader :-)) > However, I am stuck on something else, the program doesn't typecheck > because of use of another function I defined, 'cast1'. Maybe you can > take a look. I had thought that I would be able to write a generic > 'unify' but I get the error: > > GenLogVar.hs:82:19: > Ambiguous type variable `a' in the constraint: > `Data a' arising from use of `cast1' at GenLogVar.hs:82:19-23 > Probable fix: add a type signature that fixes these type variable(s) > > This is because I need to do something special when I encounter a > "Var" variable in unification, but the compiler seems to not like the > fact that the type argument of the Var data type is not known. Please try to avoid new cast operations at all costs. :-) Your code can be arranged as follows: (i) Use extQ1 to dispatch to a special case for "Var x" for the first argument. (ii) In this special case, use again ext1Q to dispatch to a special case for "Var y" for the second argument. (iii) At this point, *cast* the variable value of *one* variable to the type of the other. So the problem with your code, as it stands, is that the target type of cast is ambiguous because you cast *both* arguments. The insight is to make the cast asymmetric. Then, not even polymorphism is in our way. Interesting stuff! Ralf

2 2

Haskell on Pocket PC?
by Dmitri O.Kondratiev 03 Apr '06

03 Apr '06

Any ideas on how much work needs to be done for using Haskell on PPC Windows Mobile platform? It would be interesting to use PPC as: 1) Haskell learning tool, so small code snipets could be entered and run directly on hand-held (REPL). How hard is it to port Hugs to PPC for this? Do any other (then Hugs) implementations exist that are easier to port? 2) Running on PPC Haskell applications cross-compiled on host PC. How much work must be done for GHC to support this? 3) There are several ways both for porting Haskell to PPC as well as cross-compiling Haskell code. Which one makes more sense to implement and will take less effort: a) Porting/compiling to VM byte code (Java, Parrot)? b) Porting/compiling to .NET CLR? c) Porting/compiling source code 4) And finally, do any projects already exist in this area? It would be great to get ideas how such port can be done in reasonable amount of time, in other words to find the most easy way to start with some Haskell implementation on PPC. Thanks for any info!

3 5

Breaking up long lines
by miketerrance 03 Apr '06

03 Apr '06

What is a good technique for breaking up long lines of code (for easier readability)? I have been inserting {- -} comments but there must be a better way. Something like \ in Python? Lycos email has 300 Megabytes of free storage... Get it now at mail.lycos.co.uk

4 3

Distributing monadic(?) functions across dyadic functions
by Jared Updike 03 Apr '06

03 Apr '06

Is there a common way (standard libs, higher order) to express the lambda part below? It's not particulary complicated but I think it is not higher-order enough > unionBy (\x y -> fst x == fst y) listOfPairs1 listOfPairs2 Something like "distribute fst (==)" where > distribute f op x y = f x `op` f y would leave > unionBy (distribute fst (==)) listOfPairs1 listOfPairs2 I imagine something involving Arrows and/or zip/curry/uncurry but I just can't see it. Is this a case of trying to make something more complicated than it is? Jared. -- http://www.updike.org/~jared/ reverse ")-:"

5 4

casting numerical types
by Matthias Fischmann 02 Apr '06

02 Apr '06

hi all, this should be a quick one (for now I would be happy with a "that's impossible", just want to make sure I don't miss anything). I want to compute the average from a list of arbitrary numerical element type. I wanted to do this: avg :: (Num a) => [a] -> a avg xs = sum (map fromNum xs) / (fromIntegral (length xs)) but it doesn't compile. All I could get to work is this: avg :: (Fractional a) => [a] -> a avg xs = sum xs / (fromIntegral (length xs)) avgI :: (Integral a) => [a] -> Float avgI = avg . map fromIntegral The two function names for the same thing are tolerable, but not very elegant. Is there another option? Thanks, Matthias

3 4

Parsec operator with letter problem
by Reto Kramer 31 Mar '06

31 Mar '06

I ran into the following problem with parsec's handling of operators. I hope someone on the list can show me a trick that resolve my current issue. At the end of this message is the full code for the reproducer. The language I'm parsing has infix operators of two forms. Some are special characters (e.g. a dot) and some are LaTeX like (e.g. \in). The letters that appear in the e.g. \in lead to problems with expression parsing. The following is what I expect: $ cat input1 a.b $ ./test input1 InfixExpr OP_Dot (Ident "a") (Ident "b") Good! Then I try (change the b to an n) $ cat input2 a.n $ ./test input2 Ident "a" OUTSCH! Changing the name of an identifier changed the expression! Then I try (add a space right after the dot) $ cat input3 a. n $ ./test input2 InfixExpr OP_Dot (Ident "a") (Ident "n") Good! What is going on? The 'n' is part of the "\in" operator (see reservedOpNames in test.hs program at the end of message) and confuses the parsec expression parser's ability to determine the end of expressions/identifiers. Adding a space right after the '.' operator resolves the issue, but that's not a suitable option for my users. Unfortunately I cannot remove the "\in" operator from the reservedOpNames list since otherwise "\in" is not recognized as an infix operator itself anymore. QUESTION: how can I get parsec's expression parser to work with infix operators of the form "\in"? Thanks, - Reto -- complete reproducer (test.hs) -- compile with: ghc -o test -package parsec test.hs module Main where import List (nub) import System (getArgs) import Text.ParserCombinators.Parsec import Text.ParserCombinators.Parsec.Expr import Text.ParserCombinators.Parsec.Language( emptyDef ) import qualified Text.ParserCombinators.Parsec.Token as P main :: IO () main = do{ args <- getArgs ; let fname = args !! 0 ; input <- readFile fname ; case parse spec fname input of Left err -> do{ putStr "parse error at " ; print err } Right x -> print x } data Op = OP_Dot | OP_In deriving (Show, Eq, Ord) data Expr = InfixExpr Op Expr Expr | Ident String | Number Integer deriving (Show, Eq, Ord) spec :: Parser Expr spec = do { whiteSpace ; e <- expression ; return e } expression :: Parser Expr expression = buildExpressionParser table basicExpr <?> "expression" op_infix :: Op -> Expr -> Expr -> Expr op_infix op a b = InfixExpr op a b table :: OperatorTable Char () Expr table = [ [binary "." (op_infix OP_Dot) AssocLeft] , [binary "\\in" (op_infix OP_In) AssocLeft] ] binary name fun assoc = Infix (do{ reservedOp name; return fun }) assoc basicExpr :: Parser Expr basicExpr = choice [ do{ i <- identifier ; return $ Ident i } ] lexer = P.makeTokenParser testdef testdef = emptyDef { P.identStart = letter <|> char '_' , P.identLetter = alphaNum <|> char '_' , P.opStart = oneOf $ nub $ map (\s -> head s) $ P.reservedOpNames testdef , P.opLetter = oneOf (concat (P.reservedOpNames testdef)) , P.reservedOpNames = [ ".", "\\in" ] } dot = P.dot lexer parens = P.parens lexer braces = P.braces lexer squares = P.squares lexer semiSep = P.semiSep lexer semiSep1 = P.semiSep1 lexer commaSep = P.commaSep lexer commaSep1 = P.commaSep1 lexer brackets = P.brackets lexer whiteSpace = P.whiteSpace lexer symbol = P.symbol lexer identifier = P.identifier lexer reserved = P.reserved lexer reservedOp = P.reservedOp lexer integer = P.integer lexer natural = P.natural lexer charLiteral = P.charLiteral lexer stringLiteral = P.stringLiteral lexer

2 3

haskell-mode indentation
by Kirill Kuvaldin 31 Mar '06

31 Mar '06

Hello there. Being an emacs-addicted person, I'm using haskell-mode for editing haskell code. But its default indentation rule doesn't seem to be correct. I mean when i type something like the code below, i've got the following indentation: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Whereas the correct indentation (in my opinion) is as follows: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Thus I need hitting TAB key 2 or 3 times to make indentation as mentioned above. Cheers, Kirill

2 1

Haskell's market
by Arnaud Bailly 31 Mar '06

31 Mar '06

Hello haskellers, I have been following this list's debates for a while and I am very enthusiastic about functional programming in general and haskell in particular. I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job. The project is a Point-of-sale distributed management system with the following (non-exhaustive) list of features : - rich GUI clients (on windows platform) to allow optimizing users input speed. There will about 50-60 'screens' and half as many 'reports', - local database with possibility to replicate and aggregate data, - central repository for aggregated data, aggregation should be synchronous but may fail due to poor network connectivity, - ease of deployment/update for new versions or modules, - secured (authenticated and encrypted) communications between nodes, - ... All in all, this project is quite typical of a small to medium sized business information system which is commonplace in software services. There are no stringent performance requirements nor extraordinary functional features or tricky algorithms, but the allocated time-frame (and money :-)) is quite small and I would like to optimize design and coding time to concentrate on user acceptance, deployment and testing issues. Java and object-oriented 'paradigm' is nearly hardwired in my brain so I expect quite a painful learning process to shift towards thinking in functional terms: I know quite well the theory but never did I put it to use on a significant scale. More profoundly, I am asking myself whether this investment will be really worthwhile for this kind of software. I have read with joy and amazement S.P.Jones "Composing contracts: an adventure in financial engineering" and P.Hudak's "An experiment in software prototyping productivity", but I have also followed the discussions with J.Reymont about its poker server tester and read "Haskell vs. Erlang, Reloaded". I am not asking anyone to 'sell' me Haskell, that would be like selling ice to a penguin as I am already convinced Haskell is really interesting in itself. And I am willing to do some investment in time and money to use Haskell at the expense of another simpler but less elegant solution (read Java :-)). I would be very happy to have some feedback about these issues, regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr

6 8

Moving from Hugs to GHC and getting an error
by Adam Wyner 31 Mar '06

31 Mar '06

I developed some code in Hugs, but now am moving to GHC. I had used Hugs because I wanted to use the Trex module (extensible records), but this has not been as important as I had thought it would be. My modules run fine in Hugs, but I get an error message when I try to run my module in GHC. The message is: parse error on input `PropList' Otherwise the imported modules are interpreted. In the module, the type declarations are: type PropList = [String] type World = Int type Time = Int type SOA = Rec (properties :: PropList, time :: Time, world :: World) type DBSoas = [SOA] The error occurs just after PropList. Is there some basic difference between Hugs and GHC that I'm missing? Where can I get more information about Hugs GHC differences? Cheers, Adam

2 1

Newbie question: inferred type
by David Laffin 31 Mar '06

31 Mar '06

Hi, Newbie question. Given the inferred type for square, the inferred types for quad1, quad2 and quad3 are what I would expect. Is there a straightforward explanation (i.e. one that a newbie would understand) as to why the inferred type for quad4 is less general? Regards, dl -- GHC Interactive, version 6.4, for Haskell 98. Prelude> let square x = x * x Prelude> :t square square :: (Num a) => a -> a Prelude> let quad1 x = square (square x) Prelude> :t quad1 quad1 :: (Num a) => a -> a Prelude> let quad2 x = square $ square x Prelude> :t quad2 quad2 :: (Num a) => a -> a Prelude> let quad3 x = (square . square) x Prelude> :t quad3 quad3 :: (Num a) => a -> a Prelude> let quad4 = square . square Prelude> :t quad4 quad4 :: Integer -> Integer ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com

3 2

multiple computations, same input
by Greg Fitzgerald 31 Mar '06

31 Mar '06

How do I perform multiple computations on a long lazy list without introducing a space leak? Doing a single computation like this works great: f = show . filter (> 1) But if I do something like this: f lst = show (filter (> 1) lst, filter (> 2) lst) then it looks like GHC won't garbage collect list elements until the first filter has completely finished, and the second filter has iterated over them. Is there an easy way to feed each element into both functions, instead of feeding all elements to one function, and then all to the next? Thanks, Greg

11 20

Wrapping the IO monad to get safe, self-describing imperative APIs
by Brian Hulley 30 Mar '06

30 Mar '06

Hi - In a discussion started on the GHC mailing list http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009923.h… I discovered an idea for typing imperative API functions that may be of interest to other people, and which makes use of Haskell's type system to achieve a level of self-description and static bad-usage detection impossible in C/C++ APIs. A nicely formatted (by trac) description of the advantages and how to write such APIs is available at http://hackage.haskell.org/trac/ghc/ticket/736 (a feature request I submitted to the GHC team to make it easier to write such APIs) and the plain text is included at the end of this post. The basic idea is that different monads, which are just newtypes of the IO monad, can be used to prevent API functions being called in the wrong context. For example, consider the following C function which implements a render callback using a simplified version of DirectX to draw a square on the screen: void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } In the C code, the fact that DrawSquare() can only be called between Begin/EndScene, and the fact that Clear(), BeginScene(), EndScene() can only be called in a render callback (as opposed to a keypress callback for example) are completely implicit, and must be borne in mind by the user who has to wade through heaps of documentation to guess at this understanding. By using different monads in Haskell, the above function could be written as follows: newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () onRender :: RenderCallback -> IO () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () render :: RenderCallback render w h = do clear scene $ do drawSquare making it impossible to call drawSquare in any situation that the API did not intend, and also making it easy to see that in order to draw something, the drawing will need to be an argument of some function which makes use of DrawM () eg scene, which in turn needs to be an arg of some function which takes a RenderM () thus leading from inside out: drawSquare --> scene --> RenderCallback --> onRender. A consequence of all this is that it would be necessary (to completey enforce API correct usage) to have an extra optional entry point for Haskell programs, to prevent APIs being re-started by lifting their init functions into a callback monad (more details at the end of this post and the trac report). Regards, Brian. #736: Allowing any newtype of the IO monad to be used in FFI and extra optional entry point ------------------------------------+--------------------------------------- Reporter: brianh(a)metamilk.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: FFI foreign monad entry point Os: Multiple | Difficulty: Unknown Architecture: Multiple | ------------------------------------+--------------------------------------- Hi - When designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to use runtime checks to ensure correct usage. Consider the following callback which uses a typical C API (DirectX) to draw something to the screen: {{{ void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } }}} In Haskell with the FFI at present, we can define an equivalent API and use it as follows: {{{ type RenderCallback = Int -> Int -> IO () clear :: IO () scene :: IO () -> IO () drawSquare :: IO () onRender :: RenderCallback -> IO () runGraphicsWindow :: IO () -> IO () render :: RenderCallback render w h = do clear scene $ do drawSquare main = runGraphicsWindow $ do onRender render }}} This is all very well, but just like the C equivalent, it doesn't encode the fact that drawSquare can only be called between BeginScene and EndScene. For example the following render callback would result in a runtime error or at least an unexpected result for the user: {{{ badRender w h = drawSquare }}} To allow the type checker to enforce correct usage, we can use different monads which just wrap the IO monad as follows: {{{ newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () }}} Now the good render function is well typed and the badRender function is ill typed. With the current GHC implementation, it is possible to provide the interface above by using some fiddly wrapper functions to remove the wrapper monads and replace them with the IO monad, for example: {{{ type RenderCallbackIO = Int -> Int -> IO () foreign import ccall "wrapper" mkRenderCallbackIO :: RenderCallbackIO -> IO (FunPtr RenderCallbackIO) dropRenderM :: RenderCallback -> RenderCallbackIO dropRenderM f x y = let RenderM io = f x y in io foreign import ccall api_onRender :: FunPtr RenderCallbackIO -> IO () onRender :: RenderCallback -> IO () onRender f = mkRenderCallbackIO (dropRenderM f) >>= api_onRender foreign import ccall api_clear :: IO () clear :: RenderM () clear = liftIO $ api_clear }}} As far as I can tell, GHC currently optimizes out all the overhead involved in converting between RenderM and IO. However the extra marshalling functions are fiddly to write, in particular since different versions of dropRenderM would be needed for different numbers of arguments in whatever function returns something in RenderM, and all these extra functions also obscure the simplicity of the original design. Therefore I propose that for any monad M defined by: {{{ newtype M a = M (IO a) deriving (Functor, Monad, MonadIO) }}} M a should be able to appear in place of IO a anywhere in a foreign function definition since all 'M' does is to enforce typing on the Haskell side and has no relevance to the foreign language API, just as IO has no relevance to the foreign language either. This would mean we'd no longer have to write extra wrapper functions and rely on the compiler optimizing them out. A related point is that the "API-safety == type correctness" gained by using different monads can at the moment be subverted because the entry point into a Haskell program is the main function which returns a value of type IO (). This means that initialization code for any API must be able to run in the IO monad. However every monad discussed above allows you to lift IO operations into it, so there is nothing to stop someone trying to make a nested re-initialization of the API in the middle of a callback... It is necessary to allow IO actions to be lifted into the callback monads so the callbacks can make use of IORefs etc. However it is undesirable to allow the API to be re-initialized (in such a nested way). Therefore I propose (perhaps this should have been a separate ticket but I don't know how to link two tickets together so I've bundled both issues in this ticket) that there should be an alternative entry point into a Haskell program with the following type: {{{ newtype MainM a = MainM (IO a) deriving (Functor, Monad, MonadIO) _main :: MainM () }}} with this default implementation: {{{ _main = liftIO $ main }}} so that all existing programs will still work. If _main is explicitly defined by the user, the user's definition should be used instead, and any definition of "main" will have no special significance. This would allow the API's initialization function to be safely typed as: {{{ runGraphicsWindow :: IO () -> MainM () _main = runGraphicsWindow $ do onRender render }}} Thus the user would be prevented from making nested calls to the initialization function.

1 0

List of instantiated types
by Mirko Rahn 30 Mar '06

30 Mar '06

Hello, please suppose the following setting: (see [1] too) {-# OPTIONS_GHC -fglasgow-exts #-} module C where class C a where name :: a -> String ; pre :: a -> a data Cs = forall a . (C a) => Cs a instance C Cs where name (Cs a) = name a ; pre (Cs a) = Cs (pre a) mkCs :: C a => a -> Cs mkCs = Cs instance C Int where name = show ; pre = \ _ -> 0 instance C Char where name = return ; pre = \ _ -> 'A' all_Cs = [ mkCs (undefined :: Int), mkCs (undefined :: Char) ] Note that despite I served undefined values only I can type *C> map (name . pre) all_Cs ["0","A"] to extract some information. But, when several instances spreads over some modules, writing down 'all_Cs' is an error-prone task, in particular when using some third party modules. So my question is: Is it possible to construct 'all_Cs' automatically? I think such a list cannot be constructed at compile-time, but at link- and run-time a complete list of instantiated types should be available. But is this list accessible somehow? Is there a possibility to write foreach type t that is an instance of C: return (mkCs (undefined :: t)) What is the general problem? Thanks, MR [1] http://www.haskell.org/pipermail/haskell-cafe/2006-March/014947.html -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

2 1

Haskell saves lives :)
by Bulat Ziganshin 30 Mar '06

30 Mar '06

-- i think that this may be interesting for other haskellers Hello Wolfgang, Wednesday, March 29, 2006, 8:24:09 PM, you wrote: >> so, the concurrent programming, may be, the only area at now, where >> real-world, commercial programmers should prefer Haskell over all >> other languages. > are you a real-world, commercial programmer? If yes, I'd like to know the yes > reason(s) for you programming in Haskell. Was it Haskell's support of > concurrency? Just interested… 1. i don't write commercial apps with Haskell. although it's not entirely impossible. i've written in cafe (search for subject "Haskell's market") that i think about this now 2. programming languages is my hobby. in my feeling the main problem with C++ and Delphi (i don't used Java/C#) is that working with complex datatypes is not simple and straightforward, another problem is lack of support for anonymous code blocks (closures). even Perl beats them in these areas! Haskell attracted me due to the great type system, great closures support, type inferencing, good syntax. Having the full power of functional language to write most complex parts of code (i mean they require most complex algorithms) is very helpful. at the same time, for 80% of program speed is not matter, and FP/laziness again helps here, allowing just to write faster these parts of program. in addition, Haskell is very strong-typed language what allows to catch much more errors at compile time. these all results in what i wrote in less than one year program that is close in functionality to that others wrote in C++ during several years. this program required to write several general purpose libs and bindings to C libs, so i enlarged HCAR's hall of fame with some new entries :) about Concurrency - i was amazed how easy to use it. my first experience in this area was carrying out part of algorithm to another thread and it was implemented with just about 30-40 lines of code! i then enclosed this technique in the module that allows to use threads as message-processing systems - each has an "stdin", "stdout" and so on and there are functions that can create networks of arbitrary complexity from individual threads. again, the Haskell's type system greatly helps me here, allowing to pass between threads structured values of arbitrary types instead of just bytes - i can't imagine whether i will have enough patience to express in another language requirement that "stdout" of each thread should produce values of exact the same type as accepted by "stdin" of next thread in the pipe/network. again, Haskell saves lives :) - i mean that its powerful type system and type inferencing allowed to write type-safe code in the area where any other language would fail. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: Equirecursive types?
by lee marks 29 Mar '06

29 Mar '06

John Hughes wrote: > ... > > > Indeed, error messages in common cases would be worsened significantly, > because as Ross says, common errors (such as forgetting a parameter in a > recursive call) would lead to legal definitions that cause a type error > when applied. Partly for this reason, OCaml permits recursion only in > object types, if I remember rightly, where it's most useful. In other > cases the occurs check is still used. > Couldn't this be mitigated by requiring an explicit type annotation on the function being called recursively? In other words infinite types are never silently inferred, but can only coincide with explicit signatures. So this is legal: type Fix s a = s a (Fix s a) fold :: Functor (s a) => (s a b -> b) -> Fix s a -> b fold f = f . fmap (fold f) but this is not: fold f = f . fmap (fold f) I guess it just seems that banning infinite types altogether is throwing the baby with the bath. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

haskell programming guidelines
by Christian Maeder 28 Mar '06

28 Mar '06

Hi, haskell admits many programming styles and I find it important that several developers of a prject agree on a certain style to ease code review. I've set up guidelines (still as plain text) for our (hets) project in http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… These were inspired by C programming guidelines, http://haskell.org/hawiki/ThingsToAvoid and the problems I came across myself. It like to get comments or proposals for our or other haskell grogramming guidelines. Thanks Christian

10 31

planet.haskell.org? for Haskell blogs
by Isaac Jones 28 Mar '06

28 Mar '06

I think someone should volunteer to set up "Planet Haskell" ala Planet Debian, Planet Gnome, Planet Perl, etc. These sites are "Blog aggregators". Basically they just collect the RSS feeds of the community and post their blogs to a web page in a cute format (the gnome one is especially cute, but you probably could have guessed that). There's already software out there for this, so nothing new needs to be written. I think we need a volunteer to set this up somewhere? Preferably someone with their own server, and we'll worry about setting up the DNS later :) peace, isaac See: http://planet.debian.org/ http://planet.gnome.org/ http://planet.perl.org/

3 9

Defining instance needs allow-undecidable-instance?
by Daniel McAllansmith 28 Mar '06

28 Mar '06

Hi, folks. I've got a working class and instances thereof. I would now like to change the class such that error behaviour is specified by MonadError, for the moment throwing String errors. When I try to add MonadError into the types I eventually hit the requirement for allow-undecidable-instances. Is there some way I can I avoid having to use this extension? My starting point consists of: class (Num i, Bounded i, Monad m) => MonadSource i m | m -> i where ... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans) instance (Num i, Bounded i, Monad m) => MonadSource i (SourceT i m) where ... I changed it to: class (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i m | m -> i where .... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans, MonadError e) instance (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i (SourceT i m) where ... Thanks Daniel

2 2

Eval of a syntax tree for reduction
by Steve Downey 28 Mar '06

28 Mar '06

I'm working through Pierce's Types and Programming Languages on my own. I'm attempting to write the typecheckers in Haskell, instead of ML. However, when it comes to his eval function, I'm a little stuck. The original is let rec eval t = try let t' = eval1 t in eval t' with NoRuleApplies -> t Where eval1 is a single step evaluation of the abstract syntax tree, and NoRuleApplies is an exception that's raised if there are no rules that can reduce the expression. Now, there's a footnote that it isn't good style in ML. It seems even less natural in Haskell, at least to me, but I still don't know the language that well. The natural equivalent to what Pierce has in ML is something along the lines of data ArithExpr = TmTrue | TmFalse | TmIfExpr ArithExpr ArithExpr ArithExpr | TmZero | TmSucc ArithExpr | TmPred ArithExpr | TmIsZero ArithExpr deriving (Show, Eq) eval1 :: ArithExpr -> ArithExpr eval1 (TmIfExpr TmTrue t _) = t eval1 (TmIfExpr TmFalse _ t) = t eval1 (TmIfExpr t1 t2 t3) = let t1' = eval1 t1 in TmIfExpr t1' t2 t3 -- and so on But, how to terminate the recursion in the full eval? I'm considering changing eval1 to be ArithExpr->Maybe ArithExpr If the expression is reducible, then I return Just t, and if it's not reducible, then Nothing It makes eval1 a bit more complicated, and not as straightforward translation from the type system being described, though. e.g reducing If looks more like eval1 (TmIfExpr t1 t2 t3) = let t1' = eval1 t1 in case t1' of { Just t1'' -> Just $ TmIfExpr t1'' t2 t3 ; Nothing -> Nothing } and eval then looks like eval t = let t' = eval1 t in case t' of { Just t'' -> eval t'' ; Nothing -> t' } I'm looking for some suggestions on the direction to proceed.

3 2

Bit streams programs in Haskell
by Per Gustafsson 27 Mar '06

27 Mar '06

Haskell gurus, We have made a proposal to extend the Erlang `binary' data type from being a sequence of bytes (a byte stream) to being a sequence of bits (a bitstream) with the ability to do pattern matching at the bit level. This proposal has now been fully implemented all these at the level of the BEAM virtual machine and in the HiPE compiler. Most probably, they will be part of the next major Erlang/OTP open source release. (We write "most probably" because we do not really control what Ericsson desides to release as part of its open source system.) We wanted to evaluate the performance of our implementation and the succintness of our syntax, particularly against other `similar' languages. For this reason, we wrote five reasonably representative benchmarks, showing the things that one could employ bit stream pattern matching and bit-level comprehensions for. The benchmarks (drop3, five11, huffman, uudecode, and uuendode) have all been written in Erlang, O'Caml and Haskell. For some of them, C and Java versions exist. They can be found in the following homepage: http://bitbenches.infogami.com/ As you will see there, the Haskell numbers are significantly slower than those of Erlang and O'Caml. We are wondering why this is so. For each language, we have spent a considerable effort in writing the benchmarks in -- at least what we feel -- is the most natural and efficient way one can write them. The only constraint we impose is that for functional languages, data structures without any explicit mutation have to be used in the part of the program for which measurements are taken. Our experience in writing efficient (and beautiful) Haskell programs is close to (if not below) zero. Also, perhaps our mind might be suffering from severe case of strictness and might be completely unable to `think lazily'. So, we request your help in noticing obvious NO-NOs and stupid mistakes that we might have made. We even welcome completely different Haskell programs provided they adhere to the constraint mentioned above -- no mutation. Best regards, Kostis Sagonas and Per Gustafsson

5 6