October 2009 - Haskell-Cafe

Newcomers question
by b1g3ar5 01 Nov '09

01 Nov '09

I'm trying: instance Num b => Num (a -> b) where fromInteger = pure . Prelude.fromInteger negate = fmap Prelude.negate (+) = liftA2 (Prelude.+) (*) = liftA2 (Prelude.*) abs = fmap Prelude.abs signum = fmap Prelude.signum but the compiler rejects it with: src\Main.hs:24:9: Could not deduce (Show (a -> b), Eq (a -> b)) from the context (Num b) arising from the superclasses of an instance declaration at src\Main.hs:24:9-29 Possible fix: add (Show (a -> b), Eq (a -> b)) to the context of the instance declaration or add an instance declaration for (Show (a -> b), Eq (a -> b)) In the instance declaration for `Num (a -> b)' Could someone please explain this to me? I thought that it might be that it couldn't work out the functions necessary for (a->b) to be in the classes Show and Eq - so I tried adding definitions for == ans show, but it made no difference. Thanks

5 5

ANNOUNCE: dbus-core 0.5 and dbus-client 0.1
by John Millikin 01 Nov '09

01 Nov '09

These are pure-Haskell client libraries for using the D-Bus protocol. D-Bus is heavily used for inter-application IPC on Free and open-source desktop platforms, such as Linux, OpenSolaris, and FreeBSD. These libraries allow applications written in Haskell to inter-operate with other components of recent GNOME, KDE, and XFCE desktops. This is the first "real" release of these libraries; dbus-core has been published on Hackage for some time, but mostly just to make sure I got the Cabal bits right. I feel they are now stable / featureful enough for public use. Both are available on Hackage: http://hackage.haskell.org/package/dbus-core http://hackage.haskell.org/package/dbus-client --------- "dbus-core" is an implementation of the D-Bus protocol, specifically the parts relevant to clients. Eventually, it will probably grow some functions useful for implementing a message bus as well. It includes type mapping / conversion, an implementation of the wire format (marshaling / unmarshaling), data types for the currently defined message types (METHOD_CALL, METHOD_RETURN, ERROR, and SIGNAL) and a basic parser / generator for introspection documents. It is roughly equivalent in purpose to libdbus. By itself, a protocol implementation is somewhat cumbersome to use, so "dbus-client" is a high-level wrapper. It provides some abstractions like remote object proxies, exported object trees, synchronous method calls, signal reception, and name reservation. Messages are received and processed in separate IO threads, allowing asynchronous method call and signal handling. The purpose between splitting the library into two packages is stability; "dbus-core", ideally, will change only rarely -- performance improvements, new message / data types, etc. It provides a base level of functionality which more specialised libraries may use. "dbus-client" is an example of what such a library could look like, though for now it's not very Haskell-y (IO everywhere, exceptions, explicit locking). By separating the protocol from the client libs, alternative client libs can safely depend on the protocol implementation. --------- To see a sample of the library working, there's a clone of the "dbus-monitor" utility in <dbus-core/Examples>. Documentation is currently a bit lacking, so for now, the best documentation is the PDF of the source code itself, and the (rather barren) Haddock output: https://dl.getdropbox.com/u/1947532/dbus-core_0.5.pdf https://dl.getdropbox.com/u/1947532/dbus-core_0.5/index.html https://dl.getdropbox.com/u/1947532/dbus-client_0.1.pdf https://dl.getdropbox.com/u/1947532/dbus-client_0.1/index.html Once more people have used it without any major API issues, I'll write up a manual and populate the Haddock entries. Please respond with any feedback, difficulties, or suggestions. I'm particularly interested in ways to improve the public API, since I would rather make any breaking changes *before* anything big depends on these libraries.

2 1

ANN: mecha-0.0.1
by Tom Hawkins 31 Oct '09

31 Oct '09

Mecha is a little solid modeling language intended for machine design. Mecha has two layers: a pure functional layer for defining solids (aka. parts), and a monadic layer for arranging parts into assemblies. Solids (parts) are built using set operations on solid primitives. A solid primitives is simply a predicate that says whether a point in space is inside the solid: data Solid = Solid (Vector -> Bool) Mesh generation is performed by adaptive marching cubes. It's slow, especially if you don't have graphics hardware. And solids with hard edges don't render very clean. But the basics work. Here's a simple example: example :: IO () example = view design design :: Asm () design = do a <- part 1 0.06 8 $ difference sphereCube cyl3 b <- part 1 0.08 8 $ sphereCube c <- part 1.5 0.08 8 $ cyl3 color (0, 0, 0.8) $ place a move (-4, 0, 0) $ color (0.8, 0, 0) $ place b move ( 0, 4, 0) $ color (0, 0.8, 0) $ place c sphereCube = intersection sphere $ scaleXYZ 0.75 cube cyl = scale (0.5, 0.5, 1.2) $ cylinder cyl3 = unions [cyl, rotateX (pi / 2) cyl, rotateY (pi / 2) cyl] Screenshot: http://tomahawkins.org/ Enjoy!

2 1

ANN: Advgame 0.1.1
by Tim Wawrzynczak 31 Oct '09

31 Oct '09

Hey cafe, If any of you were (or are) Common Lispers, you may be aware of Dr. Conrad Barski's humorous and lighthearted approach to Common Lisp. As a little tribute to his CL evangelization efforts, I ported his tutorial, 'Casting SPELs in Lisp' (http://www.lisperati.com/casting.html) to Haskell. It works very similarly to his final program, except it can be run in a loop, instead of one function at a time. It's available at http://hackage.haskell.org/package/Advgame-0.1.1 if anyone is interested. Cheers, - Tim

1 0

I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
by Shelby Moore 31 Oct '09

31 Oct '09

I found the post at the following link to be the most useful in explaining declarative versus imperative: http://www.haskell.org/pipermail/haskell-cafe/2009-September/067000.html Here follows what I want to add to the discussion: http://www.haskell.org/pipermail/haskell-cafe/2009-September/067094.html John Dorsey wrote: >> Well, try this: Go ask a random person how you add up a list of numbers. >> Most of them will say something about adding the first two together, >> adding the third to that total, and so forth. In other words, the step >> by step instructions. > > You word the (hypothetical) question with a bias toward imperative > thinking. You're asking "How do you do this action?" > Why isn't the question "What is the sum of a list of numbers?", > which is biased toward the declarative? Instead ask "How do you add some numbers?" Then you will more likely get the answer, "add them together". The disconnect is that most people do not think in terms of details, so if you ask them to think in terms of how to declare "the order of the operation over the set in minimized semantics", you will push them into an area which they are not specialized. I have read the claim that Haskell tends to attract some of the most talented programmers, because it resonates with the mindset of people who like to generalize details into minimum rulesets. The most accurate question should be, "How do you add some numbers with minimized instructions?", because it forces them to realize they must order the set. An answer might be, "Zero if empty, else order the set, sum the first number with the sum of remainder of the set. Repeat for the sum of remainder." The real leap for me (not using my college math recently), and I am sure for most imperative programmers and people in general, is go from the recursive declaration above, to the notion that the declaration __IS__ the sum and does not just _return_ or output the sum. That notion becomes important when the declaration is not a single number result, instead a set. That is important because there is no way to _return_ an infinite set. The mind gets stuck on the recursive declaration of infinite sets, such as fibonacci, unless one comes from a mathematical mindset. Math is a muscle, it atrophies if you do not exercise it. And similarly to competitive muscles and aerobic capacity (speaking from my own experience), it only takes a little bit of exercise to get back to about 60% of former peak ability after a long period of no exercise.

1 1

GHC core packages: same core?
by Dimitry Golubovsky 31 Oct '09

31 Oct '09

Hi, Just curious whether package http://hackage.haskell.org/package/ghc-core and http://hackage.haskell.org/package/extcore operate on the same flavor of GHC Core? There seem to be external [1] and internal [2] flavors of GHC Core. [1] http://www.haskell.org/ghc/docs/6.10.2/html/ext-core/core.pdf [2] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType Thanks. -- Dimitry Golubovsky Anywhere on the Web

4 5

uu-parsinglib pKeyword
by Ozgur Akgun 30 Oct '09

30 Oct '09

Hi everybody, I am using the uu-parsinglib to parse a structured language and map the results to some proper data structures. Thanks to Prof Doaitse Swierstra (and other authors if any), it is fun to write a parser using this library. I've been sending private mails to Doaitse about my questions, who kindly gives nice replies everytime. But this time I thought I can ask my question to the community, and give everyone the chance to benefit from the answers. [After the intro, here comes my real question] I am trying to capture the following pattern. pKeyword_Int = ( \ _ _ _ -> "int" ) <$> pSym 'i' <*> pSym 'n' <*> pSym 't' pKeyword_Float = ( \ _ _ _ _ _ -> "float" ) <$> pSym 'f' <*> pSym 'l' <*> pSym 'o' <*> pSym 'a' <*> pSym 't' As you can see there is an obvious pattern if you try to capture a "keyword". If there were a function called pKeyword taking a string as an argument and producing the necessary parser, things would be easier. What I mean is, pKeyword_Int = pKeyword "int" pKeyword_Float = pKeyword "float" I tried to create this pKeyword function myself but I couldn't manage to do it. I can feel that, one can simply add a "<* pReturn []" to the ends of every parser and write a recursion with this base condition. Any suggestions? PS: Actually I'm a little bit uncomfortable since there may be such a function in the library already :) -- Ozgur Akgun

2 1

\Statically checked binomail heaps?
by Maciej Kotowicz 30 Oct '09

30 Oct '09

Hi, first of all this post is literate haskell I'm trying to implement a binomial heaps from okaski's book [1] but as most it's possible to be statically checked for correctness of definition. Remark that binomial heap is list of binomial trees in increasing order of rank and binomial heap of rank r is a node with r child t_1..t_r, where each t_i is binomial tree of rank r - i First I need some langue extension > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE EmptyDataDecls #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE ScopedTypeVariables #-} > module BinTree where second type-level Nats and Bools, and Void i some kind of Top for Nats > data Z > data S a > data Void > data True > data False Ok, let define some nice types ;) OrdLList is list of decreasing collections parametrised by type of element and length with is also highest rank of elements plus one, they are heterogeneous by they ranks > type Forest = OrdLList BinTree > data OrdLList (t :: * -> * -> * ) a :: * -> * where > LNil :: OrdLList t a Z > LCons :: t a n -> OrdLList t a n -> OrdLList t a (S n ) Binomial tree is here, a I know i can't check statically an heap property > data BinTree a :: * -> * where > Node :: Ord a => a -> Forest a n -> BinTree a n Heap is very similar to Forest just reversed order > data OrdGList (t :: * -> * -> * ) a :: * -> * where > GNil :: OrdGList t a Void > GCons :: Lt n m ~ True => t a n -> OrdGList t a m -> OrdGList t a n > type Heap a n = OrdGList BinTree a n Predicate for testing order in Heap > type family Lt a b > type instance Lt Z (S a) = True > type instance Lt (S a) Z = False > type instance Lt (S a) (S b) = Lt a b > type instance Lt a Void = True reflection form type-level nats to Int > class TNum a where > toNum :: a -> Int > instance TNum Z where > toNum _ = 0 > instance TNum a => TNum (S a) where > toNum _ = 1 + toNum (undefined :: a) rank of binomial tree > rank :: TNum n => BinTree a n -> Int > rank t = toNum $ undefined `asTypeOf` (getN t) > getN :: t a n -> n > getN _ = undefined :: n root of binomial trees > root :: BinTree e n -> e > root (Node x _ ) = x And finally first of quite serious function linking two trees with must have the same ranks, giving trees with rank greater by one > link :: Ord a => BinTree a n -> BinTree a n -> BinTree a (S n) > link t1@(Node x c1) t2@(Node y c2) > | x <= y = Node x $ LCons t2 c1 > | otherwise = Node y $ LCons t1 c2 some simple trees for tests > h = GCons t3 $ GCons t GNil > t = link t1 t2 > t1 = Node 3 LNil > t2 = Node 2 LNil > t3 = Node 5 LNil And sadly that's all I can write... for full functionality these data structure should have merge, insert, deleteMin, findMin, defined in [1] as fallow insTree t [] = [t] insTree t ts@(t':ts') | rank t < rank t' = t : ts | otherwise = insTree (link t t') ts' insert x = insTree (Node 0 x []) -- in [1] rank's are write explicit in nodes merge ts [] = ts merge [] ts = ts merge ts1@(t1:ts1') ts2@(t2:ts2') | rank t1 < rank t2 = t1 : merge ts1' ts2 | rank t1 > rank t2 = t2 : merge ts1 ts2' | otherwise = insTree (link t1 t2) $ merge ts1' ts2' removeMinTree [] = error "empty" removeMinTree [t] = (t,[] removeMinTree (t:ts) | root t < root t' = (t,ts) | otherwise = (t',t:ts') where (t',ts') = removeMinTree ts findMin = root . fst . removeMinTree deleteMin ts = merge (rev ts1, ts2) where (Node _ x ts1,ts2) = removeMinTree I try with all this function and with all I have problems with types the types of insTree in my opinion should be sth like: insTree :: (Min n m ~ k,TNum n, TNum m) => BinTree a n -> Heap a m -> Heap a k where Min looks like: type family Min a b type instance Min a Z = Z type instance Min Z a = Z type instance Min (S a) (S b) = S (Min a b) but this won't compile, ghc don't see that k can be the same type as m in first pattern, problems with rest of function was similar exclude removeMinTree with I have no idea what type it should have... Have anyone an idea how make this code working? Any help will be appreciated [1] Purely Functional Data Structures by Chris Okasaki. Cambridge University Press, 1998.

3 2

Upgrading an app from happstack 0.1 to happstack 0.3
by Thomas Hartman 30 Oct '09

30 Oct '09

Upgrading an app from happstack 0.1 to happstack 0.3? Save yourself a few minutes and read this first. http://blog.patch-tag.com/2009/10/30/migrating-from-happstack-0-1-to-happst… -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com

1 0

Re: How to fulfill the "code-reuse" destiny of OOP?
by oleg＠okmij.org 30 Oct '09

30 Oct '09

Magicloud Magiclouds wrote > In OOP, when I inherit a class, I also got the members of it. > But in haskell, how to inherit a "data"? Although any OOP system has by definition, objects, not all of them have classes. The best example of a classless (also called 1-level, or prototype-based) OO system is Self, which is still alive. An object is essentially a record of data members. An extended object (an object of an extended class, for a class-based OOP) is an extended record. They could be quite convenient: we can add a new field to an existing record without re-writing the complete declaration and re-using lots of the functions that dealt with the old records. The old code would just work on extended records, ignoring the added field. (I am simplifying a bit.) Lots has been written about extensible records in Haskell; some techniques (such as parameterizing a record type by a tail) have been rediscovered several times. Still a good survey of many various ways to implement extensible records in Haskell is Section 3 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf It is long, as everything else in that paper.

1 0