October 2010 - Haskell-Cafe

trouble with HDBC-mysql on Mac OS X
by Mark Lentczner 21 Nov '10

21 Nov '10

I'm having trouble with HDBC-mysql on Mac OS X (10.6, Snow Leopard). It compiles and builds fine, but when loaded (into ghci), the dynamic loader complains about not being able to find libmygcc.dylib. The issue is, MySQL's libmygcc is a static lib, not a dynamic one, so of course it won't find it. I've checked the build sequence that HDBC-mysql uses, and it calls upon mysql_config to generate the lib options. I've checked those and they are correct, expressly listing libmygcc statically (!). I've tried building against both the 64bit and 32bit versions of MySQL libs. (Suspect that only the 32bit should work.) Anyone have HDBC-mysql running on 10.6? Any ideas for me to try would be appreciated. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark

2 1

[ANNOUNCE] csound-expression - csound combinator library
by Anton Kholomiov 11 Nov '10

11 Nov '10

Hi, I'm glad to announce csound combinator library. It features liberation from id-style csound code, haskore-like composition structures, type-safe composable opcodes and simple instrument interface (no interface at all, instrument is just a function from some note representation to signal). http://hackage.haskell.org/package/csound-expression Anton

3 6

ANN: network-2.2.3, merger with network-bytestring
by Johan Tibell 11 Nov '10

11 Nov '10

Hi all, I like to announce a new version of the network package, network-2.2.3. You can install the latest version by running: cabal update && cabal install network This version marks the end of the network-bytestring package, which has now been merged into the network package. This means that efficient and correct networking using ByteStrings is available as part of the standard network package. As part of the merger, two new modules have been added: Network.Socket.ByteString and Network.Socket.ByteString.lAzy This release is backwards compatible with the previous release. Johan

3 5

Decoupling type classes (e.g. Applicative)?
by Dominique Devriese 08 Nov '10

08 Nov '10

Hi all, I have a problem with the design of the Applicative type class, and I'm interested to know people's opinion about this. Currently, the Functor and Applicative type class are defined like this: class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b My problem is that in the grammar-combinators library [1], the pure combinator is too general for me. I would propose a hierarchy like the following: class Pointed f where pure :: a -> f a class ApplicativeC f where (<*>) :: f (a -> b) -> f a -> f b The original type class Applicative can then be recovered as follows, and the applicative laws can be specified informally in this class's definition. class (Pointed f, ApplicativeC f, Functor f) => Applicative f where This would allow me to restrict injected values to stuff I can lift into Template Haskell later on: class LiftablyPointed f where pureL :: (Lift a) -> a -> f a pureL' :: a -> Q Exp -> f a class (LiftablyPointed f, ApplicativeC) => LiftablyApplicative f where This problem currently makes it impossible for me to use the (<*>) combinator and I have to redefine it under a different name (I currently use (>>>)). To me the problem seems similar to the well known example of the inclusion of the fail primitive in the monad class, where the general opinion seems to be that it was a bad idea to include fail in the Monad class (see e.g. the article on the haskell wiki about handling failure [2]). I've been thinking about the following type class design principles: * Only include two functions in the same design class if both can be implemented in terms of each other. * Only introduce a dependency from type class A to type class B if all functions in type class B can be implemented in terms of the functions in type class A or if type class A is empty. (Disclaimer: I currently do not follow these principles myself ;)) I would like to know people's opinions about this. Are there any issues with this advice that I don't see? Have other people encountered similar problems? Any interesting references? Thanks, Dominique Footnotes: [1] http://projects.haskell.org/grammar-combinators/ [2] http://www.haskell.org/haskellwiki/Failure

7 7

vector-space and standard API for vectors
by Alexey Khudyakov 06 Nov '10

06 Nov '10

Hello everyone! It's well known that Num & Co type classes are not adequate for vectors (I don't mean arrays). I have an idea how to address this problem. Conal Elliott wrote very nice set of type classes for vectors. (Definition below). I used them for some time and quite pleased. Code is concise and readable. > class AdditiveGroup v where > zeroV :: v > (^+^) :: v -> v -> v > negateV :: v -> v > > class AdditiveGroup v => VectorSpace v where > type Scalar v :: * > (*^) :: Scalar v -> v -> v > > class VectorSpace v => InnerSpace v where > (<.>) :: v -> v -> Scalar v There are few problems though. Fisrt one is inlining. Functions are not inlined so if client code uses uses stream fusion it breaks. Second is dependecies. Vector-space doesn't have big chain of dependencies. People may be reluctant to use vector-spaces just for API for small packages. My proposal is to split type classes above into separate package which provide only type classes, doesn't have any dependencies. Second point is to lean more on performance side in performance vs elegance. Add INLINE pragmas everywhere (unfortunate feature of stream fusion), move ^-^ to AdditiveGroup with default implementation. I'd like to know opinion of haskellers on this and specifically opinion of Conal Eliott as author and maintainer (I CC'ed him)

11 24

Reference for technique wanted
by Richard O'Keefe 05 Nov '10

05 Nov '10

There's a long-known technique in functional languages where [x1,...,xn] => \tail -> x1:...xn:tail xs ++ ys => f . g xs => f [] A correspondent mentioned to me that he couldn't find a reference to the idea (which I gather he had independently rediscovered). I know I've read about it somewhere. Can anyone provide a reference?

6 22

Are newtypes optimised and how much?
by Christopher Done 05 Nov '10

05 Nov '10

So I have the following nice things: {-# LANGUAGE GeneralizedNewtypeDeriving, OverloadedStrings #-} import Data.String newtype Foo = Foo { unFoo :: String } deriving (IsString) x :: Foo x = "Hello, World!" newtype Bar = Bar { unBar :: Integer } deriving (Eq,Show,Num,Integral,Real,Enum,Ord) y :: Bar y = 2 I can write literals and they will be converted to the type I wanted with no extra verbiage needed. Questions (I'm talking about GHC when I refer to compilation): (1) Are fromString and fromIntegral ran at compile time? I don't think that this is the case. I think they are just translated to fromString "Hello, World!" and fromIntegral 2 verbatim. (2) Regardless of this, the implementation of fromString and fromIntegral is essentially a no-op, it's just fromString = Foo, fromIntegral = Bar, which is in turn essentially fromString = id, fromIntegral = id, as far as I understand it. It's purely compile time. But supposing I write: fromIntegral (fromIntegral (2::Integer) :: Bar) :: Integer Is this at the end of the day equal to just (2::Integer)? Thinking simple-mindedly, I would say, yes. The compiler knows that fromIntegral :: Integer -> Bar == id, and that fromIntegral :: Bar -> Integer == id (right?). But is that the case? Perhaps the type class methods have some dictionary and thus cannot be inlined, or maybe that doesn't matter? At the end of the day what motivated me to ask these questions it that I like very much defining newtypes for most of the types I use, I have completely forgotten about `type' aliasing. I'm completely happy to write Foo and unFoo all over the place to aid my type correctness, but I want a nice generic way to convert to/from newtypes but keeping it a compile-time concept. Sometimes I have unThisThat, unTheOther, unThoseWhoShantBeNamed, etc. and it I could just use fromIntegral and fromString then that would be super. Also, is 'map unFoo' optimised away at compile-time, too? I think that it would be compiled to map id. So it would still wrap a thunk around each cons. How far does it go? So, if I go around using fromIntegral/fromString (etc. for other newtype types), is it still kept compile time? After having newtypes catch dozens of type mismatches that otherwise wouldn't unified happily but were completely wrong (e.g. wrong argument order), I've found newtype to be an indispensable part of Haskell and of writing a large piece of software. Cheers

8 14

Bug in HTTP (bad internal error handling)
by Bit Connor 03 Nov '10

03 Nov '10

Hello, I have reported this problem to the maintainer of the HTTP package about 2 weeks ago, but have not yet received a response, so I am reporting it here. I am using a recent git check out of HTTP 4000.0.10 The bufferReadLine function from Network.TCP has a bug in how it handles an IOException after it catches one. It checks for isEOFError e, and that branch of code seems to be ok. The problem is how it handles other types of IO errors. One type of such an error, for example, is: <socket: 117>: Data.ByteString.hGetLine: resource vanished (Connection reset by peer) After it catches this error, the function returns (line 376): return (fail (show e)) The "fail" is running in the Either monad (The Result type = Either). This calls the default Monad implementation of fail, which is just a call to plain old error. This basically causes the entire program to crash. A simple fix, is to instead just reraise the original error: ioError e This will propagate the error through as a normal IOException, which can then be caught by the caller (such as the caller of simpleHTTP). By looking at the library code, the same bug seems to be in other places (bufferGetBlock, bufferPutBlock), but I have only observed the bug actually occurring in bufferReadLine. Actually, it appears that simpleHTTP isn't actually supposed to throw an IOException, and it is instead supposed to return a ConnError result. So the real fix is to fix the code to make this happen. But I've found simpleHTTP to throw an IOException in a lot of circumstances, so for now I think the fix above is a good immediate solution. Thanks, Bit Connor

7 11

Scrap your rolls/unrolls
by Max Bolingbroke 03 Nov '10

03 Nov '10

Hi Cafe, In generic programming, e.g. as in "Data Types a la Carte" and Compos, you often wish to work with data types in their fix-point of a functor form. For example: """ data ListF a rec = Nil | Cons a rec newtype List a = Roll { unroll :: ListF a (List a) } """ In some presentations, this is done by factoring the fix point like so: """ newtype FixF f = Roll { unroll :: f (FixF f) } type List a = FixF (ListF a) """ This is all well and good, but it means when working with data types defined in this manner you have to write Roll and unroll everywhere. This is tedious :-( Something I have long wished for is equirecursion, which would let you write this instead: """ type List a = ListF a (List a) """ Note that we now have a type instead of a newtype, so we won't need to write any injection/extraction operators. However, currently GHC rightly rejects this with a complaint about a cycle in type synonym declarations. However, you can use type families to hide the cycle from GHC: """ type List a = ListF a (Force (ListThunk a)) data ListThunk a type family Force a type instance Force (ListThunk a) = List a """ Unfortunately, this requires UndecidableInstances (the type instance RHS is not smaller than the instance head). And indeed when we turn that extension on, GHC goes into a loop, so this may not seem very useful. However, we can make this slight modification to the data type to make things work again: """ data ListF a rec = Nil | Cons a (Force rec) type List a = ListF a (ListThunk a) """ Note that the application of Force has moved into the *use site* of rec rather than the *application site*. This now requires no extensions other than TypeFamilies, and the client code of the library is beautiful (i.e. has no rolls/unrolls): """ example, ones :: List Int example = Cons 1 (Cons 2 Nil) ones = Cons 1 ones """ We can factor this trick into a fix point combinator that does not require roll/unroll: """ type Fix f = f (FixThunk f) type List a = Fix (ListF a) data FixThunk f type family Force a type instance Force (FixThunk f) = Fix f """ The annoying part of this exercise is the the presence of a "Force" in the functor definition (e.g ListF) means that you can't make them into actual Functor instances! The fmap definition gives you a function of type (a -> b) and you need one of type (Force a -> Force b). However, you can make them into a category-extras:Control.Functor.QFunctor instance (http://hackage.haskell.org/packages/archive/category-extras/0.53.5/doc/html…) by choosing the "s" Category to be: """ newtype ForceCat a b = ForceCat { unForceCat :: Force a -> Force b } instance Category ForceCat where id = ForceCat id ForceCat f . ForceCat g = ForceCat (f . g) """ Rather than the usual "Hask" Category which is used in the standard Functor. This is somewhat unsatisfying, but I'm not sure there is a better way. I haven't seen this trick to "emulate equirecursion" before. Has it showed up anywhere else? Cheers, Max

5 8

profiling and strictness (was: Re: [Haskell-cafe] An interesting paper from Google)
by Evan Laforge 02 Nov '10

02 Nov '10

> Any time you see something "inexplicable" like lots of time being attributed > to something simple like "get", it means that something isn't strict enough > and "get" is having to force a bunch of lazy evaluations to do its job. > Since you're using State.Strict but lift-ing to get there, I'd first look at > the strictness of the monad you're lift-ing from. (I'm assuming > State.Strict does what the label says, but it's possible that it's not > strict in the way you need; strictness is kinda tricky.) Ahh, thanks, this makes sense to me. The monads involved are an ErrorT and one other strict StateT. When the monads say they are strict, they seem to mean that >>= will force the evaluation of the monadic mechanics of the first argument when the second is demanded. By "monadic mechanics" I mean the work done by >>= itself, so for StateT it binds the result of the first argument with either 'let' or '~(a, s') <-' instead of 'case' or '(a, s') <-'. So in my understanding, a lazy State will build thunks on every >>= and they won't ever be forced until you pull the final value and pass it to a strict function in IO like print or an FFI call, and then they are forced recursively, at which point there is a stack overflow unless it's a short sequence. Talking about strictness seems complicated to me because it's not really about what is actually forced, it's about who is forced by who (i.e., when 'a' is forced then 'b' will be) and whether it's forced in sequence or nested. So a strict State is also not forced until the strict IO function, but it turns into a sequential series of thunks rather than a nested one. If this is accurate, why would anyone want to use the lazy State? Anyway, State doesn't provide the really critical bit of strictness, which is in the actual state being modified. So 'State.modify' will inevitably lead to stack overflow if you don't intersperse 'get's in there. What is needed is both $! on State.put (or define your own strict modify that puts $! on put), and strictness annotation of the fields of the record that is being modified (provided it's a record and not a scalar type). In any case, ErrorT has a strict >>= by necessity, both States have a strict >>=, and all modifys and puts (I think) are strict, as are all the record fields. In any case, a simple 'get' should only have to force the state to whnf, so it shouldn't matter if the fields are huge thunks or not, so really all that should matter is if the state is already in whnf or is a huge nest of thunks. Which a strict >>= should prevent, right? This is right next to a 'lookup' function which is called twice as many times and should be doing more work since it actually looks in a Map, but is credited with less cpu and alloc. A lift . get should turn into -- ErrorT a <- do a <- StateT (\s -> return (s, s)) -- 'get' of the outer StateT return (a, s) -- >>= belongs to inner StateT return (Right a) Anyway, it's sort of a mishmash of semi inlined functions since this is especially nested and hard to understand with transformers, but it looks like a lot of applications of (\a -> (a, s)) type functions, so (,) constructors and a 'Right' constructor, inside of 'case's to make sure this are evaluations and not allocations (and I remember from the STG paper that a constructor inside a case need not even be constructed). So I don't totally understand where the forcing is happening to make credit the 'get' with so much work. BTW, I have a theory about what the '0' might mean... perhaps if a function is inlined away, it still appears in the profile list, but with 0 entries. > Moral of the story: time is accounted to the function that forces > evaluation of lazy thunks, not to the thunks themselves or the function that > created the lazy thunks. (I think the latter is impossible without passing > around a lot of expensive baggage, and in any case doesn't tell you anything > useful; unexpected functions taking a lot of time, on the other hand, tells > you right away that there's excessive laziness in the invocation somewhere > and gives you a starting point to track it down.) Indeed, this is a good point that I hadn't realized in quite that way before, but tracking it down is still the tricky part.

1 1