May 2009 - Haskell-Cafe

Parsec float
by Malcolm Wallace 28 May '09

28 May '09

>> is there any reason why float parses only positive numbers? It is usual in parsing libraries to separate the recognition of a leading sign from recognition of the number itself: the sign-only parser can be reused in many contexts, e.g. in the Haskell'98 Numeric library, there is readSigned :: Real a => ReadS a -> ReadS a which takes a secondary parser as its argument. You can instantiate that argument to any of readDec :: Num a => ReadS a readHex :: Num a => ReadS a readFloat :: Num a => ReadS a etc. I do not know if the equivalent of "readSigned" exists in Parsec, but it in polyparse's Text.Parse module, it is called "parseSigned", rather unsurprisingly. Regards, Malcolm

1 0

Stack overflow
by Krzysztof Skrzętnicki 28 May '09

28 May '09

Hello Cafe I'm currently writing an app with heavy use of message passing. To see which messages takes most of the bandwidth I wrote the following code: -- data Counter = CNT !Int !Int !Int !Int cntMsg (CNT a b c d) (MoveOther _ _) = (CNT a+1 b c d) cntMsg (CNT a b c d) (MoveSelf _) = (CNT a b+1 c d) cntMsg (CNT a b c d) (NilMsg) = (CNT a b c+1 d) cntMsg (CNT a b c d) (RoundEnd) = (CNT a b c d+1) emptyCnt = CNT 0 0 0 0 showCnt (CNT a b c d) = printf "CNT MoveOther=%d MoveSelf=%d NilMsg=%d RoundEnd=%d" a b c d -- The code for modifying the counter: (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,()))) Running it without increased stack blows it. With 200M stack I get after a second or so: CNT MoveOther=2125764 MoveSelf=0 NilMsg=0 RoundEnd=2916 The datatype itself is strict. So where is the thunk actually accumulating? Best regards Christopher Skrzętnicki

3 6

About the lazy pattern
by 张旭 28 May '09

28 May '09

Hi, I am really new to haskell. I am reading "A gentle instruction to haskell" now. And I just cannot understand the chapter below. Is there anybody who can gives me some hints about why the pattern matching for "client" is so early? How does the pattern matching works here? Thank you so much for answering my questions! Sincerely, nemo 4.4 Lazy Patterns There is one other kind of pattern allowed in Haskell. It is called a lazy pattern, and has the form ~pat. Lazy patterns are irrefutable: matching a value v against ~pat always succeeds, regardless of pat. Operationally speaking, if an identifier in pat is later "used" on the right-hand-side, it will be bound to that portion of the value that would result if v were to successfully match pat, and _|_ otherwise. Lazy patterns are useful in contexts where infinite data structures are being defined recursively. For example, infinite lists are an excellent vehicle for writing simulation programs, and in this context the infinite lists are often called streams. Consider the simple case of simulating the interactions between a server process server and a client process client, where client sends a sequence of requests to server, and server replies to each request with some kind of response. This situation is shown pictorially in Figure 2. (Note that client also takes an initial message as argument.) Figure 2Using streams to simulate the message sequences, the Haskell code corresponding to this diagram is: reqs = client init resps resps = server reqs These recursive equations are a direct lexical transliteration of the diagram. Let us further assume that the structure of the server and client look something like this: client init (resp:resps) = init : client (next resp) resps server (req:reqs) = process req : server reqs where we assume that next is a function that, given a response from the server, determines the next request, and process is a function that processes a request from the client, returning an appropriate response. Unfortunately, this program has a serious problem: it will not produce any output! The problem is that client, as used in the recursive setting of reqs and resps, attempts a match on the response list before it has submitted its first request! In other words, the pattern matching is being done "too early." One way to fix this is to redefine client as follows: client init resps = init : client (next (head resps)) (tail resps) Although workable, this solution does not read as well as that given earlier. A better solution is to use a lazy pattern: client init ~(resp:resps) = init : client (next resp) resps Because lazy patterns are irrefutable, the match will immediately succeed, allowing the initial request to be "submitted", in turn allowing the first response to be generated; the engine is now "primed", and the recursion takes care of the rest. _________________________________________________________________ Messenger安全保护中心，免费修复系统漏洞，保护Messenger安全！ http://im.live.cn/safe/

6 6

Introducing Instances in GHC point releases
by John Goerzen 28 May '09

28 May '09

So this is annoying (CCing -cafe) I need NominalDiffTime and UTCTime to have Typeable instances. In 6.10.1, they didn't ship with them out of the box, so I added them. Apparently, in 6.10.3, they DO ship with those instances out of the box. Annoyingly, that means that my code breaks on 6.10.3. Even more annoyingly, __GLASGOW_HASKELL__ is still 610, so I can't even work around this via cpphs. There appears to be no way to make code that requires those Typeable instances work with both 6.10.1 and 6.10.3. Yet another reason to avoid API incompatibilities in point releases. Does anybody have an idea on the best way to handle this? -- John Don Stewart wrote: > convertible appears broken with 6.10.3. Any thoughts? > > Writing new package config file... done. > Downloading convertible-1.0.1... > Configuring convertible-1.0.1... > Preprocessing library convertible-1.0.1... > Preprocessing executables for convertible-1.0.1... > Building convertible-1.0.1... > [1 of 8] Compiling Data.Convertible.Base ( Data/Convertible/Base.hs, dist/build/Data/Convertible/Base.o ) > [2 of 8] Compiling Data.Convertible.Utils ( Data/Convertible/Utils.hs, dist/build/Data/Convertible/Utils.o ) > [3 of 8] Compiling Data.Convertible.Instances.Map ( Data/Convertible/Instances/Map.hs, dist/build/Data/Convertible/Instances/Map.o ) > [4 of 8] Compiling Data.Convertible.Instances.Num ( Data/Convertible/Instances/Num.hs, dist/build/Data/Convertible/Instances/Num.o ) > [5 of 8] Compiling Data.Convertible.Instances.C ( Data/Convertible/Instances/C.hs, dist/build/Data/Convertible/Instances/C.o ) > [6 of 8] Compiling Data.Convertible.Instances.Time ( Data/Convertible/Instances/Time.hs, dist/build/Data/Convertible/Instances/Time.o ) > > Data/Convertible/Instances/Time.hs:61:9: > Duplicate instance declarations: > instance Typeable NominalDiffTime > -- Defined at Data/Convertible/Instances/Time.hs:61:9-32 > instance Typeable NominalDiffTime > -- Defined in time-1.1.3:Data.Time.Clock.UTC > > Data/Convertible/Instances/Time.hs:64:9: > Duplicate instance declarations: > instance Typeable UTCTime > -- Defined at Data/Convertible/Instances/Time.hs:64:9-24 > instance Typeable UTCTime > -- Defined in time-1.1.3:Data.Time.Clock.UTC > cabal: Error: some packages failed to install: > HDBC-2.1.0 depends on convertible-1.0.1 which failed to install. > convertible-1.0.1 failed during the building phase. The exception was: > >

10 16

gtk2hs, TreeView and CellRenderer
by Zefirov Sergey 28 May '09

28 May '09

As far as I can tell, there is not way to create CellRenderer that could include icons with the text (I think it is because of incompatibilities of Haskell type classes and Gtk inheritance hierarchy). Is it a good way to use CellRendererPixbuf and render to pixbufs using Cairo? I think my TreeView hierarchies won't be very big, around 1000 items for a while.

1 0

Strange type error with associated type synonyms
by Peter Berry 28 May '09

28 May '09

> {-# LANGUAGE TypeFamilies, TypeSynonymInstances, ScopedTypeVariables #-} The following is a class of memo tries indexed by d: > class Fun d where > type Memo d :: * -> * > abst :: (d -> a) -> Memo d a > appl :: Memo d a -> (d -> a) > -- Law: abst . appl = id > -- Law: appl . abst = id (denotationally) Any such type Memo d is naturally a functor: > memo_fmap f x = abst (f . appl x) The type of memo_fmap (as given by ghci) is (Fun d) => (a -> c) -> Memo d a -> Memo d c. (Obviously this would also be the type of fmap for Memo d, so we could declare a Functor instance in principle.) If we add this signature: > memo_fmap' :: Fun d => (a -> b) -> Memo d a -> Memo d b > memo_fmap' f x = abst (f . appl x) it doesn't type check: TypeSynonymTest.hs:14:17: Couldn't match expected type `Memo d1 b' against inferred type `Memo d b' In the expression: abst (f . appl x) In the definition of `memo_fmap'': memo_fmap' f x = abst (f . appl x) TypeSynonymTest.hs:14:32: Couldn't match expected type `Memo d a' against inferred type `Memo d1 a' In the first argument of `appl', namely `x' In the second argument of `(.)', namely `appl x' In the first argument of `abst', namely `(f . appl x)' Failed, modules loaded: none. As I understand it, the type checker's thought process should be along these lines: 1) the type signature dictates that x has type Memo d a. 2) appl has type Memo d1 a -> d1 -> a for some d1. 3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1 But for some reason, step 3 fails. If we annotate appl with the correct type (using scoped type variables), it type checks: > -- thanks to mmorrow on #haskell for this > memo_fmap'' :: forall a b d. Fun d => (a -> b) -> Memo d a -> Memo d b > memo_fmap'' f x = abst (f . (appl :: Memo d a -> d -> a) x) My ghc is 6.8.2, but apparently this happens in 6.10 as well. -- Peter Berry <pwberry(a)gmail.com> Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

11 26

Type class context propagation investigation
by Paul Keir 28 May '09

28 May '09

Hi, How does the context of a class instance declaration affect its subclasses? The Num class instance outlined below has its requirement for Eq and Show satisfied on the preceding lines, and the code will compile. But if I, say, add an (Eq a) constraint to the Eq instance, in preparation for a simple (==) definition, I find that the Num instance declaration is left lacking. If I add the same (Eq a) constraint now to Num, calm is restored. data Foo a = F a instance Eq (Foo a) where (==) = undefined instance Show (Foo a) where show = undefined instance Num (Foo a) (+) = undefined ... etc. The thing that confuses me with this is that it seems like Num "knows" that an (Eq a) context has been applied, and so what it sees as a problem, is somehow also the solution. Any advice/rules of thumb? Does this situation occur elsewhere? How do these constraints propagate? Thanks, Paul

3 4

Re: [Haskell-cafe] Bool as type class to serve EDSLs.
by Sebastiaan Visser 28 May '09

28 May '09

Or overloading the `whitespace operator' for several kinds of application. On May 28, 2009, at 9:50 AM, Augustsson, Lennart wrote: > And explicit desugaring of list syntax. > > -----Original Message----- > From: Sittampalam, Ganesh [mailto:ganesh.sittampalam@credit- > suisse.com] > Sent: 28 May 2009 08:46 > To: Simon Peyton-Jones; Sebastiaan Visser; Haskell Cafe > Cc: Augustsson, Lennart > Subject: RE: [Haskell-cafe] Bool as type class to serve EDSLs. > > There are multiple possible classes that you might want under > different > circumstances (I think the most interesting issue is whether the class > (==), (>) etc is in has a fundep from the type of the thing being > compared to the type of the boolean), but if NoImplicitPrelude (or > some > other extension) just desugars if-then-else into ifthenelse (with a > default implementation of ifthenelse somewhere) I think that would be > enough. > > Of course once you've got ifthenelse you find yourself wanting > explicit > desugaring of pattern matching (could view patterns help here?), > recursion (into an explicit use of fix), etc... > > Cheers, > > Ganesh > > Simon Peyton-Jones wrote: >> You are absolutely right about the tantalising opportunity. >> ...

1 0

the problem of design by negation
by Michael Mossey 28 May '09

28 May '09

This is not directly related to Haskell, but it's a thought that occurred to me after exposure to the Haskell community. I've spent most of the past 15 years doing scientific programming. The lead software architect and software managers are using good software engineering practice, though (this is *scientific* programming, not *programming by scientists*, ha ha). But, there is a particular culture in my company that has become more obvious to me by contrast to the Haskell community. I call it "design by negation." When asked to justify his design, the lead software architect explains everything that *wouldn't* work. "We couldn't have a unique key for every entry because blah blah blah. We couldn't use a garbage collector because blah blah. We couldn't write a sugar layer because then you have to document it separately blah blah." So the chosen design seems to be the only thing left after eliminating everything you can't do. I want to aspire to "positive design." I want to list the goals, and think of design as making clever choices that meet all the goals. I don't mean to suggest that design is never constrained. It often is. But it's a mindset I'm talking about. I don't like this mindset of design by negation. -Mike

12 19

Template Haskell very wordy w/r/t Decs and Types
by Ross Mellgren 28 May '09

28 May '09

Hi all, I'm writing a small module that exposes a template haskell splice that takes a (very simplified) C struct definition and builds: - A data type definition, - an instance for Data.Binary.Binary, - and optionally a pretty print function for it However, it seems to do this I have to write a bunch of really ugly code that builds up the TH data structures "by hand" because quoting only works with splices for expressions, or so it seems. For example, to generate the binary instance I have this code: import qualified Language.Haskell.TH as TH -- tyname is the name of the data type I've already created, as a TH.Name -- tempnames is a list of temporary variable names that are used in lambda patterns -- fields is a list of tuples describing each field -- makeGetExp recursively builds a monadic computation consisting mostly of Binary.getWord32be >>= \ tempvar -> ... binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) [d| get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] I'd really rather write: binaryInstDec <- [d| instance Binary.Binary $(tyname) where get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] But GHC gives me a syntax error on the tyname splice. The docs seem to indicate this is the way it is -- that splices in type locations is plain not implemented. My question is whether or not this is just the way it is, and people writing TH declaration splices tend to have to start manually assembling a bunch of it, or is there some trick I've missed? Perhaps even better are there some tricks that people tend to use to make this less painful? I did try using some of the lowercased monadic constructors in Language.Haskell.TH.Lib but I didn't seem to get anything more succint out of it. -Ross P.S. This is for a one-off weekend project, and the code is fugly, so I'm not posting it in its entirety here. If you want the whole module and are willing not to laugh, I'd be glad to send it along ;-) Background: I'm doing this because I'm writing a tool to snoop around the filesystem structures of HFS+ to try and help a friend recover some data off a sufficiently dead drive that fsck doesn't want to touch it, and I don't want to pay money just to find out the drive is too toasty to pull out the data. In any case, the HFS+ docs have a bunch of C struct definitions that comprise the structures, and I got tired of hand-writing data definitions and binary instances, so I figured I'd make TH do it for me.

4 4