December 2008 - Haskell-Cafe

Conditional properties in QuickCheck alter test data generation?
by Kevin Van Horn 19 Dec '08

19 Dec '08

I'm learning QuickCheck, and I'm puzzled by the behavior I'm seeing with conditional properties. After writing and loading a simple qsort function from a separate file, I typed these into ghci: let prop_minimum xs = (length xs > 0) ==> head (qsort xs) == minimum xs where types = xs :: [Integer] let prop_minimum1 xs = (length xs > 3) ==> head (qsort xs) == minimum xs where types = xs :: [Integer] These differ only in that prop_minimum1 uses a more restrictive condition. Then quickCheck prop_minimum outputs "OK, passed 100 tests" but quickCheck prop_minimum1 outputs "Arguments exhausted after 0 tests" Investigating with verboseCheck yields puzzling results. For example, verboseCheck prop_minimum says "OK, passed 100 tests", but some of the test instances it shows have length 0, contrary to the condition... and a significant fraction of the test instances have length > 3, or even length > 10! So why the problem when running quickCheck on prop_minimum1? Running verboseCheck prop_minimum1 just deepens the mystery. Now we see most of the test instances generated having 0 length, and none of them having length > 3. What's going on here? Why is the distribution of generated test instances so drastically altered? BTW, I'm using ghc version 6.10.1, running on Intel Mac OS 10.5.5.

5 6

RWH book club
by Don Stewart 19 Dec '08

19 Dec '08

Matt Podwysocki set up a Real World Haskell book club, http://groups.google.com/group/real-world-haskell-book-club (a mailing list on google groups), with already some 200 members discussing typical new user Haskell questions. Feel free to join if you like talking about Haskell, or teaching new users. -- Don

1 0

ANN: Thingie-0.80
by Jeff Heard 18 Dec '08

18 Dec '08

I need a better name for this, but I have software, so I shall release it with a dumb name. Thingie has just been uploaded to hackage. It is a library for creating 2D visualizations in a purely functional manner. It supports static visualizations and animation, and like most vis libraries, can probably do games as well as simple viz graphics. The backend uses Cairo for rendering, but I'm looking to port it to OpenGL/GLUT for systems where Gtk/Cairo is hard to get working (i.e. OS/X). The idea is that you create a graph of objects or function that return objects and the library renders them for you in 2D. Right now, there's one thing I would like to add to the system above all other things: The interactive system has the concept of a tracked program state that is threaded through the graph. This state is defined by a UIState class, and any state (which is a record object) must be an instance of UIState and provide the system with a certain number of getters and setters for basic bits of state. I would like to use Template Haskell to help create/derive these structures. Does anyone on the list want to help with that? Here are two examples. Each draws a smiley face, and the interactive one tracks your mouse with a little red ball. First the non-interactive: module Main where import Graphics.Rendering.Thingie.Primitives import Graphics.Rendering.Thingie.Cairo import qualified Graphics.Rendering.Cairo as Cairo smiley = Context [FillRGBA 0 0 0 0, Operator Cairo.OperatorClear] $ Group [Draw rectangleFilled{ topleft=Point2D 0 0, width=200, height=200 } ,Context [FillRGBA 1 1 0 1, OutlineRGBA 0 0 0 1, Translate 100 100, Operator Cairo.OperatorOver] $ Group [Draw arc{ radius=100, filled=True } ,Context [FillRGBA 0 0 0 1] $ Group [Draw arc{ center=Point2D (-33) (-33), radius=10, filled=True } ,Draw arc{ center=Point2D 33 (-33), radius=10, filled=True } ,Draw arc{ angle1=degrees 30, angle2=degrees 150, radius=70 }]]] main = renderObjectToPNG "smiley.png" 200 200 smiley ----- Now the interactive: import Graphics.Rendering.Thingie.Interactive import Graphics.Rendering.Thingie.BasicUIState import Graphics.Rendering.Thingie.Cairo import Graphics.Rendering.Thingie.Primitives import qualified Graphics.Rendering.Cairo as Cairo smiley = Context [FillRGBA 0 0 0 0, Operator Cairo.OperatorClear] $ Group [Draw rectangleFilled{ topleft=Point2D 0 0, width=200, height=200 } ,Context [FillRGBA 1 1 0 1, OutlineRGBA 0 0 0 1, Translate 100 100, Operator Cairo.OperatorOver] $ Group [Draw arc{ radius=100, filled=True } ,Context [FillRGBA 0 0 0 1] $ Group [Draw arc{ center=Point2D (-33) (-33), radius=10, filled=True } ,Draw arc{ center=Point2D 33 (-33), radius=10, filled=True } ,Draw arc{ angle1=degrees 30, angle2=degrees 150, radius=70 }]]] undercursor uistate = Context [FillRGBA 1 0 0 1] $ Draw arcFilled{ center=mousePosition uistate, radius=5 } scene = [StaticElement smiley (Rect2D 0 0 0 0) ,UnboundedElement undercursor] main = simpleMotionSensitiveGui defaultBasicUIState scene "smiley face"

1 1

Coroutines
by Ryan Ingram 18 Dec '08

18 Dec '08

Andrew was recently asking about co-routines. A couple of years ago, I was in much the same position as him; although I am pretty sure I had heard the term before, it seemed like a mysterious idea with no practical use. Then I learned Ruby. Ruby makes extensive use of coroutines; it's not uncommon to have three or more coroutines executing cooperatively, made simple by how easy it is to pass blocks of code around in that language. The entire collection iteration system in Ruby is based on coroutines; if an object implements "each", it can be iterated over: [1, 2, 3].each { |x| print x } Implementing "each" for a container is generally simple; you just write a loop and call "yield" def each [1 .. length].each { |index| yield self[index] } end It surprised me how simple and powerful this concept was; code that previously was incredibly ugly to write became simple. I think this abstraction is one of the big reasons for Ruby's current success. At the Haskell Symposium this year, Jesse Tov gave a talk about Session Types in Haskell, and it struck me that they are ideal for implementing coroutines in a type-safe manner. Here you can write pure functions that represent a communicating routines, and guarantee that the communication completes successfully (assuming the routines terminate, of course). Consider these two values: f1 :: Int -> (Char, ()) f2 :: (Int, Char -> String) You can see a natural way to connect them, using the duality of (a, _) and (a -> _): connect_f1f2 :: ((), String) connect_f1f2 = let (arg1, k2) = f2 (arg2, result1) = f1 arg1 result2 = k2 arg2 in (result1, result2) I implemented this idea, along with a nice syntax for these coroutines, in http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coroutine-0.1.0.0: f1 :: InSession (Int :?: Char :!: Eps) () f1 = runSession $ do x <- get put (head $ show x) return () f2 :: InSession (Int :!: Char :?: Eps) String f2 = runSession $ do put 6 result <- get return ("the answer is " ++ [result]) (Caveat: while this uses the do-notation, it's not *exactly* a monad; it's something more general than that. See Control.Monad.Indexed for the details. Thanks to the GHC team for NoImplicitPrelude!) You can then add choice, looping constructs, etc., to allow increasingly complicated protocols: peer1 :: InSession ((Int :?: Int :!: Eps) :?* Eps) Int -- read an Int, then write an Int, any number of times we are told to do so -- then return an Int peer2 :: InSession ((Int :!: Int :?: Eps) :!* Eps) [Int] -- write an Int, then read an Int, any number of times we want -- then return a list of Ints. The neat thing about this library is that the communication is completely pure! No side effects required! ghci> :t connect peer1 peer2 connect peer1 peer2 :: (Int, [Int]) -- ryan On Wed, Dec 17, 2008 at 6:54 PM, Richard O'Keefe <ok(a)cs.otago.ac.nz> wrote: > On 18 Dec 2008, at 11:26 am, Andrew Coppin wrote: >>> >>> (Also, "coroutines"? Seriously? That's hardly an obscure term in >>> programming circles.) >>> >> >> Well now, I'm curios. I've been writing computer programs since I was 9 >> years old. I hold a diploma *and* an honours degree in computer science. And >> I have never even *heard* of a coroutine. To this day I still don't know >> what it means. I rather suspect I'm not the only "programmer" on earth who >> finds themselves in this position. ;-) > > Shame on you for not reading Knuth's > "The Art of Computer Programming", Volume 1, "Fundamental Algorithms". > The then available three volumes of TAOCP > "were named among the best twelve physical-science monographs > of the century by American Scientist" "at the end of 1999". > (Fasicles 0, 2, 3, and 4 of volume 4 are now available, and > parts of fasicle 1 are on-line. Hooray hooray!) > > Quoting the first two paragraphs of the Wikipedia entry: > "In computer science, coroutines are program components that generalize > subroutines to allow multiple entry points for suspending and resuming of > execution at certain locations. Coroutines are well-suited for implementing > more familiar program components such as cooperative tasks, iterators, > infinite lists and pipes. > The term "coroutine" was originated by Melvin Conway in his seminal 1963 > paper.[1]" > > So "coroutine" has been standard hacker-type programming terminology > since 1963. I was able to use coroutines in Burroughs Extended Algol > (designed in the mid to late 60s), Simula 67, and Interlisp-D (80s). > Current languages supporting them include (thanks, Wikipedia) Lua, > Limbo, JavaScript, Python, and Ruby. Since anything with continuations > can do coroutines, we add Scheme and SML/NJ. Sather's iterators may be > a more familiar form of coroutine. You will commonly find something > like a "yield e" statement that reports the value of e to the caller > without actually returning, and "resume c" that resumes a coroutine > to get the next value. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 2

gtk2hs question - derive SettingsWindow from Window
by Cetin Sert 18 Dec '08

18 Dec '08

Hi all, For a network manager of sorts I'm working on, I want to derive a SettingsWindowClass from the WindowClass present in Gtk2Hs: I want (the) instance(s) of the SettingsWindowClass to have a field to store connection settings: 1) Is it safe to do it like this? class WindowClass self ⇒ SettingsWindowClass self where settingsWindowGetSettings :: self → IO [ConnectionSetting] settingsWindowSetSettings :: self → [ConnectionSetting] → IO () newtype SettingsWindow = SettingsWindow (Window,[ConnectionSetting]) mkSettingsWindow = SettingsWindow unSettingsWindow (SettingsWindow o) = o settingsWindowNew :: IO SettingsWindow settingsWindowNew = do win ← windowNew return $ mkSettingsWindow (win,[]) 2) Is this a common practice in gtk2hs usage? 3) And will GC properly free the memory allocated for the Window object? How is this ensured, do ForeignPtr's always call delete on the underlying C ptr when they get garbage collected? Best Regards, CS

2 1

Re: [Haskell] possible bug in pretty-1.0.1.0
by Duncan Coutts 18 Dec '08

18 Dec '08

On Mon, 2008-12-15 at 08:17 -0800, John MacFarlane wrote: > I noticed a difference in how "hang" works between pretty-1.0.0.0 and > pretty-1.0.1.0. I think it's a bug. If this isn't the right place to > report it, please let me know where I should. (Maintainer is listed > as libraries(a)haskell.org, but that is a closed mailing list. Perhaps > Cabal should include a report-bugs-at field?) I'd just like to advertise the fact that as of Cabal-1.6 you can put a bug-reports field in your .cabal file and it will be displayed by hackage. We would like to encourage all package authors to use this. It can be a mailto: url to a maintainer or mailing list or it can be a http: url to a bug tracker website. (Cabal-1.6 also supports specifying darcs/git/whatever repos) Duncan

2 2

Re: [Haskell-cafe] Functional MetaPost in 5 Steps
by Stefan Endrullis 18 Dec '08

18 Dec '08

I have the same problem with FuncMP. I've also replaced the "generate" function by a custom "toMPFile" as you suggested, but mpost still generates only an empty white sheet. I've used the simple example posted in the first message of this thread. The generated .mp file is also relatively simple (see attachment http://www.nabble.com/file/p21070707/Test.mp Test.mp ) The only problem is the line "input FuncMP", which produces additional code in the ps file and causes the white page. If you remove this line everything is fine again and you can see the text "blah". Here's the additional code FuncMP produces in the .ps file: ----------------------------------------------------------------- /xdvi$run where {pop errordict begin /undefined {} bind def end} if /fmp1 /fmp1 def /fmp8 /fmp8 def /fmp24 /fmp24 def /bitline1 {gsave pop dup scale dup length 8 mul 1 true currentpoint translate [66.66666 0 0 66.66666 0 0] 4 index imagemask pop grestore} bind def /bitline8 {gsave pop dup scale dup length 1 8 currentpoint translate [2.8 0 0 2.8 0 0] 4 index image pop grestore} bind def /bitline24 {gsave pop dup scale dup length 3 idiv 1 8 currentpoint translate [2.777777 0 0 2.777777 0 0] 4 index false 3 colorimage pop grestore} bind def /XDVIfshow {findfont exch scalefont setfont show} bind def /DVIPSfshow {exch gsave 72 TeXDict /Resolution get div -72 TeXDict /VResolution get div scale 1 DVImag div dup scale get cvx exec show grestore} bind def /fshowText {/xdvi$run where {pop XDVIfshow} {DVIPSfshow} ifelse} def /fshow { exch dup /fmp1 eq {bitline1} {dup /fmp8 eq {bitline8} {dup /fmp24 eq {bitline24} {fshowText} ifelse} ifelse} ifelse} def ----------------------------------------------------------------- You can also fix the .ps file by removing the "/fshow ..." part from the file and the text "blah" will appear in your ghostscript viewer. Well, this is my first test with FuncMP and that's why I'm asking this silly question now: Is the "fshow" function really necessary or can I remove it from every generated .ps file without problems? :) Or you know another solution? Does your generated .ps files also contain this code? If no, what version of FuncMP do you use? -- View this message in context: http://www.nabble.com/Functional-MetaPost-in-5-Steps-tp20144360p21070707.ht… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

excessive usage of CPU by threadDelay in GHCi
by Jeremy Shaw 18 Dec '08

18 Dec '08

Hello, I have the following simple program: import Control.Concurrent main = threadDelay (10^6) >> main If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it takes 0% of my CPU. It does not matter if I compile -O0, -O2, -threaded, it always uses 0% (which is good). Is it expected that threadDelay should be really expensive in GHCi? Am I doing something wrong? Or should I file a bug? Thanks. - jeremy

2 1

How to choose an arbitrary Arbitrary?
by Bas van Dijk 18 Dec '08

18 Dec '08

Hello, I was playing with the following tree type (attached below) which can be seen as the reification of an applicative. I wondered if I could define a QuickCheck Arbitrary instance for it. The only way I got it to type check however, was to give 'arg' a monomorphic type (for example: 'Gen (Tree ())'). If I left it polymorphic I got a "Ambiguous type variable in constraints" error. This is understandable because if the subtrees have polymorphic types they can be of any type: Tree Int, Tree Float, Tree String, etc. The system then doesn't know which Arbitrary to choose. My question is, is it possible to keep 'arg' polymorphic (i.e. 'Gen (Tree b)') and let the system somehow choose an arbitrary Arbitrary? I guess not, however I like to be proven wrong. regards, Bas ---------------------------------------------------- {-# LANGUAGE ExistentialQuantification #-} module Tree where import Control.Monad import Test.QuickCheck -- I'm using QuickCheck-2.1.0.1 data Tree a = Val a | forall b. Tree (b -> a) :*: Tree b instance Arbitrary a => Arbitrary (Tree a) where arbitrary = sized sizedTree sizedTree :: (Arbitrary a) => Int -> Gen (Tree a) sizedTree n | n <= 0 = liftM Val arbitrary | otherwise = liftM2 (:*:) func arg where m = n `div` 2 func = sizedTree m arg :: Gen (Tree ()) -- how to make this: -- Gen (Tree b) ??? arg = sizedTree m ----------------------------------------------------

2 2

Implementing PacMan
by Andrew Coppin 17 Dec '08

17 Dec '08

What do we think of this, folks? http://prog21.dadgum.com/23.html (And the rest in the series, obviously.) To me, it seems that this plan would *work*... but it wouldn't be very eligant. You'd have the code to respond to user input and move PacMan in one place, the code for collision detection in other place, the code that decides what to *do* about a collision somewhere else, the code for drawing the animations in yet another place... If you wanted to change one game element, you'd have to make changes scattered all over the place. The whole thing seems messy, non-modular and non-composible to my ears. Thoughts, people?

4 6