- Haskell-Cafe - Haskell.org

The kind of (->)
by jeeva suresh 01 Oct '07

01 Oct '07

Hi Guys! According ghci the kind of (->) is "?? -> ? -> *" What do the '??' mean? What is the difference between the '?' and the '*' Cheers -- -Jeeva

2 1

Yampa question
by Ryan Ingram 30 Sep '07

30 Sep '07

I'm deriving an FRP implementation based on the ideas presented in the Yampa Arcade paper (http://www.haskell.org/yale/papers/haskell-workshop03/) to improve my understanding of arrows, but I have a couple of questions. I'm using the following declaration for SF: > type DTime = Double > newtype SF a b = SF { runSF :: DTime -> a -> (b, SF a b) } which I make an arrow in the obvious way: > instance Arrow SF where > arr f = SF sf where > sf dt b = (f b, SF sf) > bc >>> cd = SF sf where > sf dt b = (d, bc' >>> cd') where > (c, bc') = runSF bc dt b > (d, cd') = runSF cd dt c > first bc = SF sf where > sf dt ~(b,d) = ((c,d), sfFirst bc') where > (c, bc') = runSF bc dt b One question I had was about the implementation of "first". Is it important that the pair match be lazy? Or is it safe to make it strict? What are the advantages and disadvantages of each choice? My other question had to do with ArrowChoice. > instance ArrowChoice SF where > left bc = SF sf where > sf dt (Right d) = (Right d, left bc) > sf dt (Left b) = (Left c, left bc') where > (c, bc') = runSF bc dt b What happens to the dt in the "Right d" case? It seems to be invisible to the inner signal function. Is this the right thing to do? I have an alternate implementation which does the following: > sf dt (Right d) = (Right d, left $ addtime dt bc) > addtime :: DTime -> SF a b -> SF a b > addtime add sf = SF sf' where > sf' dt a = runSF sf (dt + add) a but there's a pretty clear space leak here with repeated "Right" calls, and I'm not sure if the inner signal should see the lost time or not. Perhaps signal functions shouldn't be an instance of ArrowChoice at all? Any insights would be appreciated. -- ryan

2 1

Re: [Haskell-cafe] Rewriting filter with foldr
by PR Stanley 30 Sep '07

30 Sep '07

>Well, note that foldr takes a function of x, which produces a >function of xs. This function of xs either conses x onto it, or >leaves it unchanged. We can write this down explicitly by removing >the xs parameter and just writing what function should be produced: > >filter f = foldr (\x -> if (f x) then (x:) else id) [] That's one neat solution but it also raises a few questions for me: foldr :: (a -> b -> b) -> b -> [a] -> b yet you've managed to squeeze in a function that takes only one argument. How is this possible without GHCI blowing its top? 2. Could you please explain the role of the identity function (id) in your code? Where's its argument, or is it sort of implicitly noted? For example, is it the case that the second argument is held in reserve and passed to the first function which would take it, hence (x:) and id? Many thanks, Paul

3 2

Re: [Haskell-cafe] Rewriting filter with foldr
by PR Stanley 30 Sep '07

30 Sep '07

The question is asking for a new definition of filter using foldr. Sorry, I should have mentioned that before. Cheers, Paul At 14:26 30/09/2007, you wrote: >Perhaps a list comprehension better shows the intention of the >filter function: > >filter p xs = [x | x <- xs, p x] > >You can literally read that as "take all x from xs that satisfy p".

1 0

Rewriting filter with foldr
by PR Stanley 30 Sep '07

30 Sep '07

Hi filter :: (a -> Bool) -> [a] -> [a] filter f = foldr (\x -> \xs -> if (f x) then (x:xs) else xs) [] Somehow I feel this could be done more elegantly. What does the list think? Thanks, Paul

3 2

Re: [Haskell-cafe] Rewriting ord (revisited)
by PR Stanley 30 Sep '07

30 Sep '07

The second version looks very neat, certainly, though I am not entirely convinced that it's any more efficient. Still, I may be missing something. The compiler must be one hell of a machine. I wonder if the source code is available to the public. Cheers, Paul At 12:26 30/09/2007, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > >I would think that the compiler is smart enough to fuse the two loops. >That doesn't explain the performance difference though. > >Adrian > > >PR Stanley schrieb: > > Hi > > This was my original version plus some modifications as advised by the > > list: > > f c = sum [1 | x <- ['\0'..], x < c] > > > > The following version was sent by a list member: > > f c = length $ takeWhile (<c) ['\0'..] > > > > Now, the sender asserted that the first version was much too slow. I'm > > wondering how the second version is any more efficient than the first. > > Looking at them through my C programmers' eye, as it were, both would > > require at least two loops before returning the ANSI value. > > Any ideas? > > Thanks, Paul > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.7 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFG/4f+11V8mqIQMRsRAxegAJ4t5grdRDrWVWby6tjDZDdxgJ72FQCfcD7W >Mntl7FV2GpCGtpY2yP61kbk= >=l+3X >-----END PGP SIGNATURE-----

2 1

Rewriting ord (revisited)
by PR Stanley 30 Sep '07

30 Sep '07

Hi This was my original version plus some modifications as advised by the list: f c = sum [1 | x <- ['\0'..], x < c] The following version was sent by a list member: f c = length $ takeWhile (<c) ['\0'..] Now, the sender asserted that the first version was much too slow. I'm wondering how the second version is any more efficient than the first. Looking at them through my C programmers' eye, as it were, both would require at least two loops before returning the ANSI value. Any ideas? Thanks, Paul

2 1

Compiling Simple Regex Program
by Andrew Trusty 30 Sep '07

30 Sep '07

Hello, I'm using GHC 6.6.1 under Windows XP and I can't get the following simple program to compile. import Text.Regex main = putStrLn (subRegex (mkRegex "c") "abc" "a") It runs in GHCi just fine but GHC gives the following output when trying to compile: project1.o(.text+0x169):fake: undefined reference to `regexzmcompatzm0zi71_Textz iRegex_mkRegex_closure' project1.o(.text+0x1f7):fake: undefined reference to `regexzmcompatzm0zi71_Textz iRegex_subRegex_closure' project1.o(.rodata+0x4):fake: undefined reference to `regexzmcompatzm0zi71_Textz iRegex_mkRegex_closure' project1.o(.rodata+0x8):fake: undefined reference to `regexzmcompatzm0zi71_Textz iRegex_subRegex_closure' collect2: ld returned 1 exit status

2 1

build problem (X11 under cabal)
by Jens Blanck 29 Sep '07

29 Sep '07

Not being very savvy in building things I got stuck when trying to build xmonad. It needs X11 1.2.2, so I tried to build that. Configuration step went fine (I believe), but buiding failed: > runhaskell Setup.hs build Preprocessing library X11-1.2.2... /usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status linking Graphics/X11/Types_hsc_make.o failed command was: /usr/bin/ghc-6.6 -lX11 Graphics/X11/Types_hsc_make.o -o Graphics/X11/Types_hsc_make Setup.hs: got error code while preprocessing: Graphics.X11.Types I have tried the ghc command seperately with the flag -L/usr/X11R6/lib which makes it compile. But I cannot figure out how to proceed from here. Jens

2 1

Re: [Haskell] Seemingly impossible Haskell programs
by Roberto Zunino 29 Sep '07

29 Sep '07

Graham Hutton wrote: > Readers of this list may enjoy the following note by > Martin Escardo, which shows how to write a number of > "seemingly impossible Haskell programs" that perform > exhaustive searches over spaces of infinite size, by > exploiting some ideas from topology: > > http://math.andrej.com/2007/09/28/seemingly-impossible-functional-programs/… Very nice! The note shows that you can actually compute (forall p) where p is a *total* predicate over streams of Bool (a.k.a. infinite lazy lists). Indeed, (writing [] for streams) forall :: ([Bool] -> Bool) -> Bool seems impossible to compute. Here's what I understood: (which might be wrong, of course!) This apparent magic relies on the fact that any total predicate over (total) bool streams, i.e. p :: [Bool] -> Bool can only inspect a _finite_ prefix of the input list. More importantly, the length of the inspected prefix has an upper bound which depends _only_ on p and not on the actual input of p. In rough formulas forall p, exists n:nat, forall l:[Bool], forall l':[Bool], p l == p (take n l ++ l') So, with some nice laziness tricks, you can actually check p over "all" the infinite [Bool] space, using only finite time. Zun.

2 1