- Haskell-Cafe - Haskell.org

Call for Haskell.org committee self-nominations
by Gershom B 06 Apr '15

06 Apr '15

Dear Haskellers, We have been overdue for some time in calling for a new round of nominations to the Haskell.org Committee. We have three members due for retirement -- Jason Dagit, Edward Kmett, and Brent Yorgey. The committee would like to thank them for their excellent service. To nominate yourself, please send an email to committee at haskell.org by 21 April 2015. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. More details about the committee's roles and responsibilities are on *https://wiki.haskell.org/Haskell.org_committee <https://wiki.haskell.org/Haskell.org_committee>* If you have any questions about the process, please feel free to e-mail us at committee at haskell.org or to contact one of us individually. Regards, Gershom

1 0

How to implement a source-sink pattern
by Roland Lutz 06 Apr '15

06 Apr '15

Hi! I'm trying to implement a source-sink type of pattern where there are a number of sinks, each connected to exactly one source, and a number of sources, each connected to zero or more sinks. The program consists of some modules, each defining their own sources and sinks. To illustrate this, here's what this would look like in C: /* global.h */ struct source { char *state; /* some more fields */ } struct sink { struct source *source; char *state; /* some more fields */ } struct sink **get_sinks_for_source(struct source *source); /* module_a.c */ struct source a_source, another_source; struct sink foo, bar, baz; ... foo.source = &a_source; ... Since getting the list of sinks for a source is a common operation, I'd probably define some kind of reverse map which is updated when a sink is remapped to a new source. I tried to rebuild this in Haskell, but the result is ridiculously complicated. Since I can't use pointers, I had to define an ordinal type class to enumerate the sources and sinks and use this to look up the actual data from the world state. But then I couldn't define the Sink type properly as I can't do: data SinkInfo = Source a => SinkInfo { sinkSource :: a, sinkState :: String } I have to add the source type as a type attribute, leading to a world state with as many parameters as there are sinks. Also, I couldn't figure out how to implement a function like sinksForSource :: Source a => WorldState p q r -> a -> [Sink b => b] since the source types won't match the type of the lookup key, and the sinks can be from different modules. Now here is the actual code (comments indicate where I intend to split it into individual files): {- Global.hs -} data SourceInfo = SourceInfo { sourceState :: String } class Eq a => Source a where getSourceInfo :: WorldState p q r -> a -> SourceInfo data SinkInfo a = SinkInfo { sinkSource :: a, sinkState :: String } class Sink a where getSinkInfo :: Source x => WorldState x x x -> a -> SinkInfo x -- should allow different arguments to WorldState {- ModuleA.hs -} data ModuleASource = ASource | AnotherSource deriving (Eq) instance Source ModuleASource where getSourceInfo world ASource = aSource $ moduleAState world getSourceInfo world AnotherSource = anotherSource $ moduleAState world data ModuleASink = Foo | Bar | Baz instance Sink ModuleASink where getSinkInfo world Foo = foo $ moduleAState world getSinkInfo world Bar = bar $ moduleAState world getSinkInfo world Baz = baz $ moduleAState world data ModuleAState p q r = ModuleAState { aSource :: SourceInfo, anotherSource :: SourceInfo, foo :: SinkInfo p, bar :: SinkInfo q, baz :: SinkInfo r } sinksForSourceInModuleA :: Source x => ModuleAState x x x -> x -> [ModuleASink] -- should allow different arguments to ModuleAState and return Sink b => [b] sinksForSourceInModuleA (ModuleAState _ _ foo bar baz) source = (if sinkSource foo == source then [Foo] else []) ++ (if sinkSource bar == source then [Bar] else []) ++ (if sinkSource baz == source then [Baz] else []) {- Main.hs -} data WorldState p q r = WorldState { moduleAState :: ModuleAState p q r } initState :: WorldState ModuleASource ModuleASource ModuleASource initState = WorldState $ ModuleAState (SourceInfo "a source init state") (SourceInfo "another source init state") (SinkInfo ASource "foo init state") (SinkInfo ASource "bar init state") (SinkInfo AnotherSource "baz init state") remapBar :: WorldState p q r -> WorldState p ModuleASource r remapBar (WorldState a) = WorldState $ a { bar = SinkInfo AnotherSource (sinkState $ bar a) } sinksForSource :: Source x => WorldState x x x -> x -> [ModuleASink] -- should allow different arguments to ModuleAState and return Sink b => [b] sinksForSource (WorldState a) source = sinksForSourceInModuleA a source main :: IO () main = let before = initState after = remapBar before in do putStrLn $ "Number of sinks for another source before: " ++ (show $ length $ sinksForSource before AnotherSource) putStrLn $ "Number of sinks for another source after: " ++ (show $ length $ sinksForSource after AnotherSource) There are some problems with this code: * I couldn't figure out how to resolve the circular references which are created by splitting this into individual files. * Source and sink ordinals can't be mixed between modules, so I wouldn't be able to add a module B anyway. * Looking up the source/sink states by ordinal keys is kind of cumbersome but works. * To get the list of sinks connected to a given source, the whole world state has to be polled. I expect this to be grossly inefficient (unless Haskell does some magic here) but I'm not sure how to add a cache in a consistent way. I can't believe this should be so complicated in Haskell, so I guess I'm trying to do this in an un-Haskell-ish way, or maybe there's something obvious I haven't seen. I'd be happy about any suggestions. Roland

3 4

Initializing dynamic libraries
by Henk-Jan van Tuyl 06 Apr '15

06 Apr '15

L.S., I am using C++ dynamic libraries via a dynamic library written in C. The first thing my Haskell software does, is calling a C function to initiate the C++ libraries; but the C++ libraries generate warnings about not being able to set certain things, before the Haskell program initializes everything. Is there some automatic call to the dynamic libraries done, before execution of the main function in the Haskell program? Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

2 1

Functional dependencies conflict
by Daniel Trstenjak 05 Apr '15

05 Apr '15

Hi, I'm getting the compile error: Gamgine/Image/PNG/Internal/Parser.hs:14:10: Functional dependencies conflict between instance declarations: instance Monad m => Stream LB.ByteString m Word8 -- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10 instance Monad m => Stream LB.ByteString m Char -- Defined in ‘Text.Parsec.Prim’ The relevant stuff from the parsec 3.1.9 code[1] is: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, UndecidableInstances #-} ... import qualified Data.ByteString.Lazy.Char8 as CL import qualified Data.ByteString.Char8 as C ... class (Monad m) => Stream s m t | s -> t where uncons :: s -> m (Maybe (t,s)) instance (Monad m) => Stream CL.ByteString m Char where uncons = return . CL.uncons instance (Monad m) => Stream C.ByteString m Char where uncons = return . C.uncons And from my code[2] is: {-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses, FlexibleContexts #-} ... import qualified Data.ByteString.Lazy as LB ... instance (Monad m) => Stream LB.ByteString m Word8 where uncons = return . LB.uncons As you can see, the instances are for different ByteString types, therefore I don't quite get where GHC sees here any conflicts. Greetings, Daniel [1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs [2] https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Par…

3 5

Generalizing "unlift" functions with monad-control
by Michael Snoyman 05 Apr '15

05 Apr '15

I'm trying to extract an "unlift" function from monad-control, which would allow stripping off a layer of a transformer stack in some cases. It's easy to see that this works well for ReaderT, e.g.: {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} import Control.Monad.Trans.Control import Control.Monad.Trans.Reader newtype Unlift t = Unlift { unlift :: forall n b. Monad n => t n b -> n b } askRun :: Monad m => ReaderT r m (Unlift (ReaderT r)) askRun = liftWith (return . Unlift) The reason this works is that the `StT` associated type for `ReaderT` just returns the original type, i.e. `type instance StT (ReaderT r) m a = a`. In theory, we should be able to generalize `askRun` to any transformer for which that applies. However, I can't figure out any way to express that generalized type signature in a way that GHC accepts it. It seems like the following should do the trick: askRunG :: ( MonadTransControl t , Monad m , b ~ StT t b ) => t m (Unlift t) askRunG = liftWith (return . Unlift) However, I get the following error message when trying this: foo.hs:11:12: Occurs check: cannot construct the infinite type: b0 ~ StT t b0 The type variable ‘b0’ is ambiguous In the ambiguity check for the type signature for ‘askRunG’: askRunG :: forall (t :: (* -> *) -> * -> *) (m :: * -> *) b. (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘askRunG’: askRunG :: (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) Adding AllowAmbiguousTypes to the mix provides: foo.hs:17:30: Could not deduce (b1 ~ StT t b1) from the context (MonadTransControl t, Monad m, b ~ StT t b) bound by the type signature for askRunG :: (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) at foo.hs:(12,12)-(16,25) ‘b1’ is a rigid type variable bound by the type forall (n1 :: * -> *) b2. Monad n1 => t n1 b2 -> n1 (StT t b2) at foo.hs:1:1 Expected type: Run t -> Unlift t Actual type: (forall (n :: * -> *) b. Monad n => t n b -> n b) -> Unlift t Relevant bindings include askRunG :: t m (Unlift t) (bound at foo.hs:17:1) In the second argument of ‘(.)’, namely ‘Unlift’ In the first argument of ‘liftWith’, namely ‘(return . Unlift)’ I've tested with both GHC 7.8.4 and 7.10.1. Any suggestions?

3 7

Is it possible for cabal sandboxes to use $HOME/.cabal/lib?
by Aldo Davide 05 Apr '15

05 Apr '15

Hi all, There are some packages that I use again and again and I would like to install them once (but not in a system-wide location) and then have cabal sandboxes use that install, instead of installing them in every sandbox, which is time consuming. Is there a way do that? For example, I noticed that cabal, when operating inside a sandbox, can still find the packages installed system-wide, but not the ones in $HOME/.cabal/lib. Can I change that? Thanks

5 8

Help wanted: working on the GHC webpage
by Austin Seipp 03 Apr '15

03 Apr '15

Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Re: [Haskell-cafe] An Easy Solution to PVP Bounds and Cabal Hell
by Olaf Klinke 02 Apr '15

02 Apr '15

I am mostly a consumer of Haskell and have not worked much with the interior of cabal or GHC, but Thomas Tuegel correctly pointed out that with version numbers a package can never safely depend on another package version that was released after itself. The empirical approach of trying builds is probably the most inclusive one. But let us think why dependencies can break a package. It is because a function was removed from the namespace, conflicting things have been added to the namespace, a data type definition has changed or the modules have been re-structured. In the worst case, none of the above has happened but the semantics of a function has changed without affecting its type. But all other cases can be dealt with: When importing a module, either a smart compiler figures out or the programmer states explicitly which imported functions are expected to be provided by the imported module and what type they have. Thus, the version number of a package is replaced by the collection of classes, types and type signatures its modules export. After all, the version number can be seen as a crude „hash“ of this information. For example, instead of stating import Data.List (mapAccumL) on would say import Data.List (mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])) or rather the compiler would fill in this information and save it together with the package as a dependency. Now when a new version of Data.List comes out, it can be automatically checked whether all functions _used_ by the importing module are still exported and have the same type signature. Modulo semantics, this should be a pretty good estimate of whether a build will fail or succeed. One could possibly even add QuickCheck properties to the signatures stating that the imported functions are expected to behave in a certain way in the importing module. When installing the new package on a system, all these assertions need to be checked. Isn’t that what configure scripts do prior to executing a makefile? Olaf

1 0

Haskell-programming sysadmin opportunity at SFLC
by Clint Adams 02 Apr '15

02 Apr '15

The Software Freedom Law Center is seeking a motivated systems administrator for our small office, where we use only free and open source software. The Systems Administrator will be responsible for three main areas of work: systems maintenance, user support, and systems development. Our existing systems are a collection of Debian servers that provide central services to the office. In addition to Debian, we use: - Apache - Asterisk - Ceph - deets - dirvish and BoxBackup - Ganeti with Xen and KVM - Gitolite - Hakyll - hledger and hledger-web - Ikiwiki - Monkeysphere - Nginx - OpenLDAP - OpenVPN - Postfix/SpamAssassin/Dovecot - Radicale - Yesod as well as a number of other systems. Ideal candidates will have experience with most of these components and the ability to quickly master the ones they know less about. As our new Systems Administrator, you will be responsible for maintaining and rebuilding our servers as necessary so some knowledge of server components and hardware configuration will be needed. You should have experience with firewall management and secure network design. Experience with low-latency bandwidth shaping preferred. Programming experience with Perl, Python, Haskell, and shell scripts will also be necessary for maintaining legacy systems. In addition to the servers, you will also be responsible for supporting 5—10 desktop users with their daily use of free software. Additional help with this activity is available around the office and many users are self-supporting for local system issues. All office user machines are running Debian. You will be frequently tasked with other functions, which may include code analysis, explaining technological concepts and licensing to lawyers, community outreach, and anything else which may require technical expertise. We intend to continue to improve our free software technology for running our law practice. There are many challenging projects we’d like to do and about which we hope you will be excited. Experience working with software development in addition to systems administration is therefore a big plus. Position includes full benefits. Please submit a cover letter and resume in a free document format to officemanager(a)softwarefreedom.org Applications should be submitted no later than April 15, 2015

1 0

cabal haddock --executables
by Maurizio Vitale 02 Apr '15

02 Apr '15

I'm getting: cabal: internal error when calculating transitive package dependencies. Debug info: [] and it seems this has been a problem for quite some while (and it has to do with the executable depending on a local library) is there any known workaround? Thanks, Maurizio

2 2