January 2012 - Haskell-Cafe

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 06 Jan '12

06 Jan '12

'Antoine Latter' <aslatter(a)gmail.com>: > All of this is in my head, but assuming I already had some sort of > Linux build-server set up, it would be nice to combine it with your > work to make it easier to have the build-server run tests against > multiple versions of GHC/HP. That's all I was getting at. Working within the Hub framework this is straightforward. If you are using public releases rather than special builds of the tools then it should be quite easy. Supposing you needed to test with Haskell Platform 2011.2.0.1 and hexpat-0.19.7: # install the platform (probably done already) sudo yum install haskell-platform-2011.2.0.1-hub # create new hub 'test-2011.2.0.1' based this HP hub init 2011.2.0.1 test-2011.2.0.1 # install hexpat-0.19.7 into it hub install-into test-2011.2.0.1 hexpat-2011.2.0.1 Repeat as necessary to create your array of test environments. Now you just have to arrange select the appropriate hub for each test. Suppose the environment variable $testhubs contains all of your test hubs ('test-2011.2.0.1', etc.), then the following shell command would prime the tools to successively use each of the test environments on each invocation of make. for h in $testhubs; do HUB=$h make; done Note that the justhub distribution isn't necessary for this -- you can do it manually. But it does make it easier. Chris

2 4

Re: [Haskell-cafe] Solved but strange error in type inference
by Yves Parès 06 Jan '12

06 Jan '12

2012/1/6 AUGER Cédric <sedrikov(a)gmail.com> > when you write "forall a. exists b. a -> b -> a", then you allow the > caller to have access to b to produce a (didn't you write "a->b->a"?) > Yes, sorry, I always assumed independence between the type variables. Like in: f :: forall a. a -> (forall b. b -> a) being the same than: f :: forall a b. a -> b -> a I should have specified: "*if* a doesn't depend on b in the latter." Of course the latter allows that, whereas the first does not (since its what prevents STRefs from escaping runST, by forbidding the return type of runST to depend on the phantom type 's' of the ST action).

2 1

Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
by "Philip K. F. Hölzenspies" 06 Jan '12

06 Jan '12

Dear Steve, et al., On 6 Jan 2012, at 11:00, <haskell-cafe-request(a)haskell.org> <haskell-cafe-request(a)haskell.org> wrote: > From: Steve Horne <sh006d3592(a)blueyonder.co.uk> > Date: 6 January 2012 10:51:58 GMT > To: Steffen Schuldenzucker <sschuldenzucker(a)uni-bonn.de> > Cc: Haskell Cafe Mailing List <haskell-cafe(a)haskell.org> > Subject: Re: [Haskell-cafe] Simple type-class experiment turns out not so simple... > > > On 06/01/2012 10:29, Steffen Schuldenzucker wrote: >> With 'd' not being mentioned anywhere, the signature of wbtData means "forall d. n -> Maybe d". In particular, wbtData == const Nothing. >> > I'm not sure what to make of that. Even if the result of wbtData is always Nothing, surely it still has a static type? I think what Steffen was saying here is that the only implementation of wbtData that satisfies the general type "forall d. n -> Maybe d" is "const Nothing" which has precisely that static type (the forall doesn't make it a dynamic type). > Precisely that. In that case, I get... > > C:\_SVN\dev_trunk\haskell\examples>ghci -XMultiParamTypeClasses > GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Prelude> :load BinTree > [1 of 1] Compiling BinTree ( BinTree.hs, interpreted ) > > BinTree.hs:12:12: > Illegal instance declaration for `WalkableBinTree (BT x) x' > (All instance types must be of the form (T a1 ... an) > where a1 ... an are *distinct type variables*, > and each type variable appears at most once in the instance head. > Use -XFlexibleInstances if you want to disable this.) > In the instance declaration for `WalkableBinTree (BT x) x' > Failed, modules loaded: none. > Prelude> > > If I specify both extensions (-XMultiParamTypeClasses and -XFlexibleInstances) it seems to work, but needing two language extensions is a pretty strong hint that I'm doing it the wrong way. This isn't a general truth, but if you're still in early stages of learning about GHCs type-class implementation, you're probably right. > The goal is fairly obvious - to have type-classes for binary tree capabilities so that different implementations can support different subsets of those capabilities. Being able to walk a binary tree doesn't need ordering of keys, whereas searching does. A red-black tree needs somewhere to store it's colour in the node, yet the walking and searching functions don't need to know about that. The problem with the "forall d. n -> Maybe d" type is that it makes d too general (universal, in fact), while d is fixed by n. There is an alternative extension you may want to look into for your furtherance of the capabilities of GHC, being TypeFamilies. These would lead to the following alternative implementation: {-# LANGUAGE TypeFamilies #-} class WalkableBinTree n where type ElemTp n wbtChildren :: n -> Maybe (n, n) wbtData :: n -> Maybe (ElemTp n) instance WalkableBinTree (BT x) where type ElemTp (BT x) = x wbtChildren (Branch d l r) = Just (l, r) wbtChildren Empty = Nothing wbtData (Branch d l r) = Just d wbtData Empty = Nothing This says that the instance fixes the "element type" ElemTp to something specific. However, it seems perfectly reasonable for the goal you describe to demand that whatever tree-type this class is instantiated for must be parametric in its element type. This can be done without any language extension, i.e.: class WalkableBinTree n where wbtChildren :: n d -> Maybe (n d, n d) wbtData :: n d -> Maybe d instance WalkableBinTree BT where wbtChildren (Branch d l r) = Just (l, r) wbtChildren Empty = Nothing wbtData (Branch d l r) = Just d wbtData Empty = Nothing Notice that now, the class is instantiated for "BT" and *not* "(BT x)". > As far as I remember, none of the tutorials I've read have done this kind of thing - but it seemed an obvious thing to do. Obviously in the real world I should just use library containers, but this is about learning Haskell better in case a similar problem arises that isn't about binary trees. A good way to learn a lot about type classes is to study the default library. Admittedly, this can be a bit of a daunting task to just dive in. Luckily, Brent Yorgey wrote up a nice article that was transferred and updated by numerous people on the HaskellWiki. It's worth giving it a read: http://www.haskell.org/haskellwiki/Typeclassopedia Happy Haskelling! Regards, Philip

1 0

How to split this string.
by max 06 Jan '12

06 Jan '12

I want to write a function whose behavior is as follows: foo "string1\nstring2\r\nstring3\nstring4" = ["string1", "string2\r\nstring3", "string4"] Note the sequence "\r\n", which is ignored. How can I do this?

13 28

haxr standalone server?
by Johannes Waldmann 06 Jan '12

06 Jan '12

How could I use haxr (http://www.haskell.org/haskellwiki/HaXR) to build a stateful server? It should listen on some port, and fork threads (inside Haskell land) to handle incoming calls. Any of the Haskell web frameworks can do this? I guess this is the same question as: http://www.haskell.org/pipermail/haskell-cafe/2009-December/071185.html Thanks - J.W.

4 6

ghc default options
by Victor Miller 06 Jan '12

06 Jan '12

Is there a place where I can specify default options for ghc? I just installed ghc 7.0.4 on my Redhat system. Since gmp isn't available on our system libraries I installed gmp in the lib file in my home directory. I've set LIB_PATH and LD_LIBRARY_PATH to point to it. ghci works ok (it finds the dynamic link library in my directory), but unless I add -L$HOME/lib as an option to ghc --make it can't find it. So how can I tell ghc to look in that directory by default? Because of this I can't install the haskell platform. Victor PS. I spent a while looking at the ghc manual but couldn't find anything appropriate.

2 1

Monadic computation must now do IO, fails when type changed to IO.
by Matthew Farkas-Dyck 06 Jan '12

06 Jan '12

Dear fellow Haskellers, I have written an SMTP server (Main.hs at http://hpaste.org/56134, full git repo at http://strake.zanity.net:1104/ymail.git) which works, mostly – it responds to every message with that it was sent properly, whether it was or not. (Try it: send an e-mail by SMTP to this_is_not_a_user(a)strake.zanity.net or somesuch.) The reason is, that it simply tells the message (envelope, data) in a Writer monad, which is later piped to the local delivery agent. As I said, this works, but of course is suboptimal. I tried to change the type of main_ to (MonadState MTPState m, MonadIO m) => [Char] -> m ([Char], [Char]), just calling LDA in main_ (when mode is MTPTextMode) rather than after, but then the program output nil. I'm not sure what the problem is – I thought IO might not be lazy enough so I tried a lazy wrapped-IO monad, in vain. How, then, can this program call the LDA, wait to know whether it worked or failed, and then respond? Thanks for any help. Cheers, M Farkas-Dyck

1 0

Type class for sequences with dependent types
by Robbert Krebbers 06 Jan '12

06 Jan '12

Hello, in a Haskell development I have to represent paths that have elements of alternating types. GADTs allow me to do this easily: data AltList :: * -> * -> * where Nil :: AltList a a ICons :: Int -> AltList Int b -> AltList () b UCons :: () -> AltList () b -> AltList Int b Since I have various kinds of these data structures I defined a type class for common operations on such data structures. class DepSequence l where nil :: l a a app :: l a b -> l b c -> l a c The instance for AltList is as follows: instance DepSequence AltList where nil = Nil Nil `app` k = k ICons i l `app` k = ICons i (l `app` k) UCons i l `app` k = UCons i (l `app` k) This all works nicely, however, I also want ordinary lists to be an instance of this class too. I tried the following: type IntListAlt a b = [Int] instance DepSequence IntListAlt where nil = [] app = (++) But GHC does not like this, it yields: Type synonym `IntListAlt' should have 2 arguments, but has been given none In the instance declaration for `DepList IntListAlt' The following alternative works, but it is quite ugly newtype IntList a b = IntList { getList :: [Int] } instance DepSequence IntList where nil = IntList [] app l k = IntList (getList l ++ getList k) and also does not give me a nil of type [Int] and an app of type [Int] -> [Int] -> [Int]. Does anyone know whether Haskell allows me to do this in a better way? Best, Robbert

3 3

Sudden monomorphism with -XTypeFamilies
by Rian Hunter 05 Jan '12

05 Jan '12

hello i'm getting inconsistent monomorphism behavior with the same code only depending on whether or not -XTypeFamilies is enabled: ---- {-# LANGUAGE TypeFamilies #-} snda :: a -> b -> b snda ba = id main = do let ma = (return () :: IO ()) mBox bb = snda ma bb mBox $ return (4 :: Int) mBox $ return "G" return () ---- in the preceding example, if -XTypeFamilies is enabled then "mBox" is monomorphic and the program will terminate early, otherwise, it's polymorphic and the program will complete successfully. i think i understand why this is the case but i couldn't find documentation on this inconsistency anywhere. is this expected behavior or is this a bug in GHC? thanks! rian

2 1

Re: [Haskell-cafe] Package Versioning Policy
by Christoph Breitkopf 05 Jan '12

05 Jan '12

Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf < chbreitkopf(a)googlemail.com> wrote: > Hello, > > I'm trying to figure out how to handle versioning of my IntervalMap > package. I've just read the package versioning policy: > http://www.haskell.org/haskellwiki/Package_versioning_policy > > I don't quite understand all the recommendations in the above document, > though: > > a) You are not allowed to remove or change the types of existing stuff. Ok. > > b) You are allowed to add new functions. But that can break compilation > because of name conflicts. Seems to be allowed on the grounds that this is > easy to fix in the client code. > > c) You are not allowed to add new instances. I don't get this - how is > this any worse than b)? > > I do understand that it is not generally possible to prevent breaking code > - for example if the client code depends on buggy behavior that gets fixed > in a minor version update. That seems unavoidable - after all, bugfixes are > _the_ reason for minor updates. > > Regards, > > Chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 6