October 2005 - Haskell-Cafe

Help using QuickCheck
by Benjamin Franksen 23 Oct '05

23 Oct '05

Hello All, I am asking help with using QuickCheck. I tried everything I could think of, but invariably as soon as I start invoking the quickCheck function on my property it fails with *Data.FingerSearchTreeUtil> Top level: No instance for (Show (IO ())) arising from use of `print' at Top level Probable fix: add an instance declaration for (Show (IO ())) In a 'do' expression: print it <interactive>:1:0: No instances for (Arbitrary (OrdSeq Int), Show (OrdSeq Int)) arising from use of `quickCheck' at <interactive>:1:0-20 Probable fix: add an instance declaration for (Arbitrary (OrdSeq Int), Show (OrdSeq Int)) In the definition of `it': it = quickCheck prop_DeleteInsert The property is quite a simple one: prop_DeleteInsert x xs = delete x (insert x xs) == xs where types = xs :: OrdSeq Int My code compiles just fine with ghc. I tried some examples from the QuickCheck manual and these seem to work; at least I get the expected "OK, passed 100 tests.". What am I doing wrong? Besides, there are some really non-obvious quirks with QuickCheck. For instance, the following one caused me some headache: I downloaded the haskell script 'quickCheck' and modified the line where ghci is executed like this: system ("/usr/bin/ghci -cpp -package QuickCheck "++options opts'++" <hugsin") (I am using ghc 6.4.1, btw). Running 'quickCheck Data/FingerSearchTreeUtil.hs' gives me: <interactive>:1:0: Failed to load interface for `QuickCheck': Could not find module `QuickCheck': it is a member of package util-1.0, which is hidden Strange. Replacing 'ChickCheck' with 'util' gives me the above error message about "No instance for (Show (IO ()))..." Ben

3 6

RE: [Haskell-cafe] FastString a misnomer
by Simon Marlow 22 Oct '05

22 Oct '05

On 21 October 2005 02:53, Donald Bruce Stewart wrote: > john: >> On Thu, Oct 20, 2005 at 10:45:28AM +0100, Simon Marlow wrote: >>> I think when this is ready it should replace Data.PackedString. >>> >>> I don't necessarily mean put it into fptools/libraries/base - we >>> could just remove the existing Data.PackedString from there and >>> your separate package can provide Data.PackedString. That is, >>> unless we decide to use it in GHC in some way, in which case we'll >>> have to pull (a copy of) it into fptools/libraries. >> >> We should make 'PackedString' the UTF8 wrapper though and provide >> Data.ByteArray as a separate library. If it has string in the name, >> one should be able to replace strings with it everywhere and expect >> the right thing to happen as enforced by the type system. that and >> C's conflation of characters and bytes and Haskell 98s lack of >> clearing up the issue has been a huge pet peeve of mine. > > Ok, so a rough structure of the final lib would be: > > Data Data System > | | | > ByteArray (?) PackedString Posix > | | | > UTF8 Latin1 ... MMap (providing > mmapFile :: FilePath -> ByteArray) Remind me what Data.ByteArray is for? Seems like it would overlap a lot with Data.PackedString.Latin1 and UArray Word8. We should have Data.PackedString.UTF16 too; it'll make interoperating with Win32 APIs easier as Bulat pointed out. I like John Meacham's suggestion of changing the UTF8 representation to include a count of characters as well as bytes. I'm not volunteering to do it, just adding my "+1" in case anyone else wanted to :-) Cheers, Simon

3 2

RE: [Haskell-cafe] FPS lib
by Simon Marlow 22 Oct '05

22 Oct '05

On 19 October 2005 01:08, Donald Bruce Stewart wrote: > However, on my machine: > > OpenBSD/Pentium-M 1.6G/ghc-6.5 -O > Elapsed time: FPS Simon's PackedString > Krasimir's test1 1.966s (40M) 2.151s (36M) > 2.235s (36M) test2 6.048s (24M) 3.160s (73M) > 2.318s (39M) > > Which is basically what I expected. Though perhaps I need to improve > concat (we currently do things a little strangely in concat, due to > the darcs legacy), but pack itself is nice and fast. > > Linux/Pentium 4 3.6G/ghc-6.4.1 -O > test1 35.37s 30.97s 2.180s > test2 90.93s 60.55s 1.916s > > Ah!! So what's going on on Linux, I wonder. Could it be something > about > 6.4.1? Are we seeing the difference between ForeignPtrs from 6.4 to > 6.5? I will investigate. I bet that's the difference between ForeignPtrs in 6.4.1 and 6.5. I'm very tempted to merge the ForeignPtr optimisations into 6.4.2, so we can benefit from this earlier. The changes are all confined to one module (GHC/ForeignPtr.hs). BTW, concat isn't optimised in my library. It's defined like this: concat pss = pack $ Prelude.concat $ Prelude.map unpack pss which is why I'm not winning this benchmark :) > I'd be very wary of switching entirely to non-portable ghc > primop-based code, as FPS already run ons hugs and I think nhc. Yes, I think the benchmarks will ultimately show that using ByteArray# isn't worth much, if any, performance gain. Cheers, Simon

3 2

RE: [Haskell-cafe] FastString a misnomer
by Simon Marlow 21 Oct '05

21 Oct '05

On 20 October 2005 09:48, Donald Bruce Stewart wrote: > bulatz: >> Hello John, >> >> Thursday, October 20, 2005, 4:12:36 AM, you wrote: >> >>> FastString seems to be a misnomer for this library. >> >>> what it provides is a fast _byte array_ with a lot of useful >>> operations, but it does not provide strings since it does not >>> enforce character encodings in the type system, which would be >>> vital for a real FastString library. In any case, just had to get >>> that off my chest :) >> >> may be it can be named ByteArray? and then FastString.Latin1, >> FastString.UTF8... will use its utilities >> >> also, all UTF8 utilities may be placed outside of FastString.UTF8 >> module, because it can be used for something else >> >> btw, FastString is also a bit misnamed. it's really a CompactString. >> ghc's FastString was named so, imho, just because they provided >> hashes for fast string comparision > > Well, it's a PackedString really, isn't it? I changed it to FastString > after too many people grumbled about colliding with the existing > PackedString. I think when this is ready it should replace Data.PackedString. I don't necessarily mean put it into fptools/libraries/base - we could just remove the existing Data.PackedString from there and your separate package can provide Data.PackedString. That is, unless we decide to use it in GHC in some way, in which case we'll have to pull (a copy of) it into fptools/libraries. Cheers, Simon

6 6

Haskell and OS X
by Patrick Collison 21 Oct '05

21 Oct '05

Hi, I'm looking to get started developing Haskell under OS X, and I'm wondering what sort of IDE/implementation combinations people find productive. I've got haskell mode working with Emacs and ghc, this works okay, though the mode seems a little rough-edged, and the indentation appears slightly wonky at times. I didn't immediately stumble across any native OS X IDEs. What do OS X-based Hasellers tend to use? Thanks, Patrick

6 9

Re: [Haskell-cafe] Re: Haskell and OS X
by Joel Reymont 21 Oct '05

21 Oct '05

On Oct 21, 2005, at 5:54 PM, J. Garrett Morris wrote: > Can I throw a vote in for handling > > data T = T { granularity :: (Int, Int, Int, Int) > , items :: Map (Int, Int, Int, Int) [Item] } How is this supposed to align? It aligns like this for me. Thanks, Joel -- http://wagerlabs.com/

2 1

RE: [Haskell-cafe] Template Haskell -- Bug?
by Simon Peyton-Jones 21 Oct '05

21 Oct '05

| $ ghc --make THTest1.hs | Chasing modules from: THTest1.hs | Compiling THTest1TH ( ./THTest1TH.hs, ./THTest1TH.o ) | Compiling THTest1 ( THTest1.hs, THTest1.o ) | | THTest1.hs:10:4: `incrSelf' is not a (visible) method of class `IncrSelf' This is definitely a bug. I'll look into it. Thanks! Simon

1 0

RE: [Haskell-cafe] Re: "getServiceEntry: does not exist" on Windows
by Simon Marlow 21 Oct '05

21 Oct '05

Nope, actually it also happens for me with the updated installer. Sigbjorn - any ideas? It doesn't happen with my local STABLE build, but I'm still using gcc 3.2.x. Cheers, Simon On 21 October 2005 13:33, Simon Marlow wrote: > Please try the updated installer for 6.4.1. I believe this is caused > by the same bug in the dynamic linker that was fixed in the update. > At least, I can reproduce your bug with the 6.4.1 installation I > have, but not with a fresh build. > > Cheers, > Simon > > On 21 October 2005 13:20, Joel Reymont wrote: > >> Folks, ideas on this? It's a major showstopper for me since it >> prevents me from deploying the Haskell app for my customer :(. >> >> Thanks, Joel >> >> On Oct 19, 2005, at 5:06 PM, Joel Reymont wrote: >> >>> This fails also but the C call to getprotobyname succeeds. >>> >>> Prelude> Network.BSD.getProtocolByName "tcp" >>> *** Exception: getServiceEntry: does not exist (no such service >>> entry) >>> >>> On Oct 19, 2005, at 4:51 PM, Joel Reymont wrote: >>> >>> >>>> I checked my Windows protocol file in system32/drivers/etc and it >>>> has >>>> >>>> tcp 6 TCP # Transmission control protocol >>>> >>>> Still, I get the following: >>>> >>>> Prelude> Network.BSD.getProtocolNumber "tcp" >>>> *** Exception: getServiceEntry: does not exist (no such service >>>> entry) >>>> >>> >>> -- >>> http://wagerlabs.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2

FFI and modifying haskell memory
by Joel Reymont 21 Oct '05

21 Oct '05

Folks, I stumbled upon this when binding the Zlib library and want to make sure I'm doing this right. foreign import ccall unsafe "uncompress" uncompress_ :: Ptr Word8 -> Ptr CULong -> Ptr Word8 -> CULong -> IO CInt You give this function the address of your size as second argument and it updates size for you. basic uncompress(char* buf, unsigned long *size, ...) for you. Is it correct that I need to allocate a chunk of 4 bytes to be passed into C and updated there and then need to peek my value from that chunk of memory? I thought StablePtr would give me the address of a Haskell value but it gives me an offset into some table instead. Thanks, Joel -- http://wagerlabs.com/

1 0

Re: [Haskell-cafe] Regular Expressions without GADTs
by oleg＠pobox.com 21 Oct '05

21 Oct '05

Conor McBride wrote: > Neither Oleg nor Bruno translated my code; they threw away my > structurally recursive on-the-fly automaton and wrote combinator parsers > instead. That's why there's no existential, etc. The suggestion that > removing the GADT simplifies the code would be better substantiated if > like was compared with like. ... > I'm sure the program I actually wrote can be expressed with the type > class trick, just by cutting up my functions and pasting the bits into > individual instances; the use of the existential is still available. I > don't immediately see how to code this up in Bruno's style, but that > doesn't mean it can't be done. Still, it might be worth comparing like > with like. Please see the enclosed code. It is still in Haskell98 -- and works in Hugs. > I suspect that once you start producing values with the > relevant properties (as I do) rather than just consuming them (as Oleg > and Bruno do), the GADT method might work out a little neater. Actually, the code is pretty much your original code, with downcased identifiers. It faithfully implements that parser division approach. Still, there are no existentials. I wouldn't say that GADT code is so much different. Perhaps the code below is a bit neater due to the absence of existentials, `case' statements, and local type annotations. {-- Haskell98! --} module RegExps where import Monad newtype Zero = Zero Zero -- Zero type in Haskell 98 -- Bruno.Oliveira's type class class RegExp g where zero :: g tok Zero one :: g tok () check :: (tok -> Bool) -> g tok tok plus :: g tok a -> g tok b -> g tok (Either a b) mult :: g tok a -> g tok b -> g tok (a,b) star :: g tok a -> g tok [a] data Parse tok t = Parse { empty :: Maybe t , divide :: tok -> Parse tok t} parse :: Parse tok a -> [tok] -> Maybe a parse p [] = empty p parse p (t:ts) = parse (divide p t) ts liftP f p = Parse{empty = liftM f (empty p), divide = \tok -> liftP f (divide p tok)} liftP2 mf p1 p2 = Parse{empty = mf (empty p1) (empty p2), divide = \tok -> liftP2 mf (divide p1 tok) (divide p2 tok)} lsum x y = (liftM Left x) `mplus` (liftM Right y) lprod x y = liftM2 (,) x y -- Conor McBride's parser division algorithm instance RegExp Parse where zero = Parse mzero (\_ -> zero) one = Parse (return ()) (\_ -> liftP (const ()) zero) check p = Parse mzero (\t -> if p t then liftP (const t) one else liftP (const t) zero) plus r1 r2 = Parse (lsum (empty r1) (empty r2)) (\t -> plus (divide r1 t) (divide r2 t)) mult r1 r2 = Parse (lprod (empty r1) (empty r2)) (\t -> let (q1,q2) = (divide r1 t, divide r2 t) lp x1 = liftP (either id ((,) x1)) in maybe (mult q1 r2) (\x1 -> lp x1 (plus (mult q1 r2) q2)) (empty r1)) star r = Parse (return []) (\t-> liftP (uncurry (:)) (mult (divide r t) (star r))) p1 :: RegExp g => g Char ([Char], [Char]) p1 = mult (star (check (== 'a'))) (star (check (== 'b'))) testp = parse (star (mult (star (check (== 'a'))) (star (check (== 'b'))))) "abaabaaabbbb" {- *RX> testp Just [("a","b"),("aa","b"),("aaa","bbbb")] -} testc = parse (star one) "abracadabra" -- Parsing the list of integers ieven = even :: Int->Bool iodd = odd :: Int->Bool p2 :: RegExp g => g Int (Either (Int, (Int, [Int])) (Int, [Int])) p2 = plus (mult (check iodd) (mult (check iodd) (star (check ieven)))) (mult (check ieven) (star (check iodd))) test2 = parse (star p2) [1::Int,1,2,3,3,4]

4 4