January 2012 - Haskell-Cafe

Is the haddock generator on Hackage down?
by Bardur Arantsson 03 Jan '12

03 Jan '12

Hi all, No Haddock documentation seems to have been generated on Hackage in the past few days. See e.g. http://hackage.haskell.org/package/copilot-2.0.3 or http://hackage.haskell.org/package/derive-2.5.5 Does anyone know if the cron job (or whatever) isn't running for some reason? Cheers,

2 1

space-efficient, composable list transformers [was: Re: Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]]
by Sebastian Fischer 03 Jan '12

03 Jan '12

Hello Heinrich, On Tue, Dec 27, 2011 at 1:09 PM, Heinrich Apfelmus < apfelmus(a)quantentunnel.de> wrote: > Sebastian Fischer wrote: > >> all functions defined in terms of `ListTo` and `interpret` >> are spine strict - they return a result only after consuming all input >> list >> constructors. > > Indeed, the trouble is that my original formulation cannot return a result > before it has evaluated all the case expressions. To include laziness, we > need a way to return results early. > > Sebastian's ListTransformer type does precisely that for the special > case of lists as results, Hmm, I think it does more than that.. (see below) but it turns out that there is also a completely generic way of returning > results early. In particular, we can leverage lazy evaluation for the > result type. > This is nice! It would be cool if we could get the benefits of ListConsumer and ListTransformer in a single data type. I know that you chose these names to avoid confusion, but I would like to > advertise again the idea of choosing the *same* names for the constructors > as the combinators they represent [...] This technique for designing data > structures has the huge advantage that it's immediately clear how to > interpret it and which laws are supposed to hold. I also like your names better, although they suggest that there is a single possible interpretation function. Even at the expense of blinding eyes to the possibility of other interpretation functions, I agree that it makes things clearer to use names from a *motivating* interpretation. In hindsight, my names for the constructors of ListTransformer seem to be inspired by operations on handles. So, `Cut` should have been named `Close` instead.. > Especially in the case of lists, I think that this approach clears up a > lot of confusion about seemingly new concepts like Iteratees and so on. A share the discomfort with seemingly alien concepts and agree that clarity of exposition is crucial, both for the meaning of defined combinators and their implementation. We should aim at combinators that people are already familiar with, either because they are commonplace (like id, (.), or fmap) or because they are used by many other libraries (like the Applicative combinators). A good way to explain the meaning of the combinators is via the meaning of the same combinators on a familiar type. Your interpretation function is a type-class morphism from `ListTo a b` to `[a] -> b`. For Functor we have: interpret (fmap f a) = fmap f (interpret a) On the left side, we use `fmap` for `ListTo a` on the right side for `((->) l)`. Similarly, we have the following properties for the coresponding Applicative instances: interpret (pure x) = pure x interpret (a <*> b) = interpret a <*> interpret b Such morphism properties simplify how to think about programs a lot, because one can think about programs as if they were written in the *meaning* type without knowing anything about the *implementation* type. The computed results are the same but they are computed more efficiently. Your `ListTo` type achieves space efficiency for Applicative composition of list functions by executing them in lock-step. Because of the additional laziness provided by the `Fmap` constructor, compositions like interpret a . interpret b can also be executed in constant space. However, we cannot use the space efficient Applicative combinators again to form parallel compositions of sequential ones because we are already in the meaning type. We could implement composition for the `ListTo` type as follows (<.) :: ListTo b c -> ListTo a [b] -> ListTo a c a <. b = interpret a <$> b But if we use a result of this function as argument of <*>, then the advantage of using `ListTo` is lost. While interpret ((,) <$> andL <*> andL) runs in constant space, interpret ((,) <$> (andL <. idL) <*> (andL <. idL)) does not. The ListTransformer type supports composition in lock-step via a category instance. The meaning of `ListTransformer a b` is `[a] -> [b]` with the additional restriction that all functions `f` in the image of the interpretation function are incremental: xs `isPrefixOf` ys ==> f xs `isPrefixOf` f ys Composition as implemented in the ListTransformer type satisfies morphism properties for the category instance: transformList id = id transformList (a . b) = transformList a . transformList b As it is implemented on the ListTransformer type directly (without using the interpretation function), it can be combined with the Applicative instance for parallel composition without losing space efficiency. The Applicative instance for `ListTransformer` is different from the Applicative instance for `ListTo` (or `ListConsumer`). While interpret ((,) <$> idL <*> idL) is of type `[a] -> ([a],[a])` transformList ((,) <$> idL <*> idL) is of type `[a] -> [(a,a)]`. We could achieve the latter behaviour with the former instance by using an additional fmap. But uncurry zip <$> ((,) <$> idL <*> idL) has the same disadvantages regarding space efficiency as referred to above because the computation of `zip` cannot occur in lock-step with another computation. The meaning of the Applicative instance of `ListTransformer` can again be described using morphism properties on Applicative structures. The corresponding structure on the meaning type `[a] -> [b]` is the following combination of the Applicative instances for functions and for ZipLists. fmap f a = liftA (fmap f) a pure x = pure (getZipList (pure x)) a <*> b = getZipList <$> liftA2 (<*>) (ZipList <$> a) (ZipList <$> b) I have a gut feeling that the laziness provided by the `Fmap` constructor is too implicit to be useful for the kind of lock-step composition provided by ListTransformer. So I don't have high hopes that we can unify `ListConsumer` and `ListTransformer` into a single type. Do you have an idea? Sebastian

3 3

Avoiding parametric function binding
by Kevin Quick 03 Jan '12

03 Jan '12

I'm having some difficulty avoiding a tight parametric binding of function parameters, which is limiting the (de)composability of my expressions. I'm curious as to whether there is an option or method I haven't tried to achieve this. Here's an example test case: > data Var = V1 (Maybe Int) > | V2 (Maybe String) > > test = V1 (Just 1) Given this structure, I can do something like this: > elemStr :: (Show a) => Maybe a -> String > elemStr = show > > varStr (V1 x) = elemStr $ id x > varStr (V2 x) = elemStr $ id x > > main = putStrLn . varStr $ test This operation extracted the internal value from the Var container, and then passes it to a parametric function (id) and that result to another parametric function with a class restriction on the input. This is fine so-far. However, what I'd like to do is decompose this to allow more flexibility (using id is pretty boring) without having to repeat the extraction boilerplate each time. My first attempt: > varElem :: forall x . (Show x) => Var -> x > varElem (V1 x) = x > varElem (V2 x) = x > > main = putStrLn . elemStr . varElem $ test This fails because even though I've specified the same class constraint for the output type of varElem that elemStr requires on its input element, the compiler binds the parametric type of x when it processes the first (V1) definition and fails with an error on the second definition because it asserts that x must be an Int and it found a String. I realized that the parametric output type was awkward, so I tried inverting the design (somewhat similar to fmap): > onVarElem :: forall a . (Show a) => (Maybe a -> String) -> Var -> String > onVarElem f (V1 x) = f x > onVarElem f (V2 x) = f x > > main = putStrLn . onVarElem elemStr $ test This is probably a better design, but still fails for the same reason: Couldn't match expected type `Int' with actual type `[Char]' Expected type: Maybe Int Actual type: Maybe String In the first argument of `f', namely `x' In the expression: f x Even changing onVarElem so the second parameter was a simple variable and performing the pattern match in an internal where or let binding failed because the first application of f bind its parametric values. Is there a way to delay this parametric binding to allow composable function specifications? Thanks, Kevin -- -KQ

4 5

More cabal install problems
by Victor Miller 03 Jan '12

03 Jan '12

I've been trying to install threadscope on my macbook pro runing OSX 10.7 (Lion). This hasn't been easy. Thanks to help here, I finally got glib installed, but now one of the hangups is in installing the package gio. The following happens: Building gio-0.12.2... Building library... creating dist/build /usr/bin/ghc --make -package-name gio-0.12.2 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Idist/build/autogen -Idist/build -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id array-0.3.0.2-143060371bda4ff52c270d1067551fe8 -package-id base-4.3.1.0-239d76b73f466dc120129098b3472858 -package-id bytestring-0.9.1.10-5bb17614aed376ea31b721a9272770b1 -package-id containers-0.4.0.0-b4885363abca642443ccd842502a3b7e -package-id glib-0.12.2-185c12da89238d25c489c0b80fc015c5 -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b -O -XHaskell98 -XForeignFunctionInterface System.GIO System.GIO.Enums System.GIO.Types System.GIO.Async.AsyncResult System.GIO.Signals System.GIO.Async.Cancellable System.GIO.File.AppInfo System.GIO.File.ContentType System.GIO.File.FileAttribute System.GIO.File.File System.GIO.File.FileEnumerator System.GIO.File.FileInfo System.GIO.File.FileMonitor System.GIO.File.IOError System.GIO.File.MountOperation System.GIO.Icons.Emblem System.GIO.Icons.EmblemedIcon System.GIO.Icons.FileIcon System.GIO.Icons.Icon System.GIO.Icons.ThemedIcon System.GIO.Volumes.Drive System.GIO.Volumes.Mount System.GIO.Volumes.Volume System.GIO.Volumes.VolumeMonitor <command line>: cannot satisfy -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b (use -v for more information) World file is already up to date. cabal: Error: some packages failed to install: gio-0.12.2 failed during the building phase. The exception was: ExitFailure 1 ------- However, cabal list tells me: * mtl Synopsis: Monad classes, using functional dependencies Default available version: 2.0.1.0 Installed versions: 2.0.1.0 License: BSD3 which tells me that the version of mtl that's desired is already installed. Any suggestions? Victor

2 2

On the purity of Haskell
by Steve Horne 02 Jan '12

02 Jan '12

This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs "Tackling the Awkward Squad". I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction. Warning - it may look like trolling at various points. Please keep going to the end before making a judgement. To make the context explicit, there are two apparently conflicting viewpoints on Haskell... 1. The whole point of the IO monad is to support programming with side-effecting actions - ie impurity. 2. The IO monad is just a monad - a generic type (IO actions), a couple of operators (primarily return and bind) and some rules - within a pure functional language. You can't create impurity by taking a subset of a pure language. My view is that both of these are correct, each from a particular point of view. Furthermore, by essentially the same arguments, C is also both an impure language and a pure one. See what I mean about the trolling thing? I'm actually quite serious about this, though - and by the end I think Haskell advocates will generally approve. First assertion... Haskell is a pure functional language, but only from the compile-time point of view. The compiler manipulates and composes IO actions (among other things). The final resulting IO actions are finally swallowed by unsafePerformIO or returned from main. However, Haskell is an impure side-effecting language from the run-time point of view - when the composed actions are executed. Impurity doesn't magically spring from the ether - it results from the translation by the compiler of IO actions to executable code and the execution of that code. In this sense, IO actions are directly equivalent to the AST nodes in a C compiler. A C compiler can be written in a purely functional way - in principle it's just a pure function that accepts a string (source code) and returns another string (executable code). I'm fudging issues like separate compilation and #include, but all of these can be resolved in principle in a pure functional way. Everything a C compiler does at compile time is therefore, in principle, purely functional. In fact, in the implementation of Haskell compilers, IO actions almost certainly *are* ASTs. Obviously there's some interesting aspects to that such as all the partially evaluated and unevaluated functions. But even a partially evaluated function has a representation within a compiler that can be considered an AST node, and even AST nodes within a C compiler may represent partially evaluated functions. Even the return and bind operators are there within the C compiler in a sense, similar to the do notation in Haskell. Values are converted into actions. Actions are sequenced. Though the more primitive form isn't directly available to the programmer, it could easily be explicitly present within the compiler. What about variables? What about referential transparency? Well, to a compiler writer (and equally for this argument) an identifier is not the same thing as the variable it references. One way to model the situation is that for every function in a C program, all explicit parameters are implicitly within the IO monad. There is one implicit parameter too - a kind of IORef to the whole system memory. Identifiers have values which identify where the variable is within the big implicit IORef. So all the manipulation of identifiers and their reference-like values is purely functional. Actual handling of variables stored within the big implicit IORef is deferred until run-time. So once you accept that there's an implicit big IORef parameter to every function, by the usual definition of referential transparency, C is as transparent as Haskell. The compile-time result of each function is completely determined by its (implicit and explicit) parameters - it's just that that result is typically a way to look up the run-time result within the big IORef later. What's different about Haskell relative to C therefore... 1. The style of the "AST" is different. It still amounts to the same thing in this argument, but the fact that most AST nodes are simply partially-evaluated functions has significant practical consequences, especially with laziness mixed in too. There's a deep connection between the compile-time and run-time models (contrast C++ templates). 2. The IO monad is explicit in Haskell - side-effects are only permitted (even at run-time) where the programmer has explicitly opted to allow them. 3. IORefs are explicit in Haskell - instead of always having one you can have none, one or many. This is relevant to an alternative definition of referential transparency. Politicians aren't considered transparent when they bury the relevant in a mass of the irrelevant, and even pure functions can be considered to lack transparency in that sense. Haskell allows (and encourages) you to focus in on the relevant - to reference an IORef Bool or an IORef Int rather than dealing with an IORef Everything. That last sentence of the third point is my most recent eureka - not so long ago I posted a "Haskell is just using misleading definitions - it's no more transparent than C" rant, possibly on Stack Overflow. Wrong again :-( So - what do you think?

25 119

Experiments in Haskell Packaging
by Chris Dornan 02 Jan '12

02 Jan '12

[I am sorry for if get two copies of this -- no sign of the first copy.] The justhub.org Haskell distribution for Enterprise Linux (RHEL/CentOS 5 & 6) is now live. The distribution deviates from current practice. When you upgrade to a new Haskell Platform you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one. Why? • Stability: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC 4.1.2 and Binutils 2.17.50.) • Flexibility: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable. • Sandboxes: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use Hubs instead.) • Package Deletion: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code. • The Catalogue: All of the GHC releases can be added as they become available. In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution. But after an upgrade: • any projects configured to work with specific tool chains and libraries will continue undisturbed; • you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out); • even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch. Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating. It might also help new users to make the transition to serious developers more quickly. Thoughts anyone? Chris

1 0

proxy settings with simpleHttp
by hanjoosten 02 Jan '12

02 Jan '12

Hi, I am fiddling around with the package http-enumerator to download web pages. I was used to `simpleHttp` do do that. However, I would like to infuence the proxy settings, because sometimes I am behind a firewall. Is there a simple way to do this? Thanks! Han. -- View this message in context: http://haskell.1045720.n5.nabble.com/proxy-settings-with-simpleHttp-tp51149… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

Experiments in Haskell Packaging
by Chris Dornan 02 Jan '12

02 Jan '12

Hi All, The http://justhub.org Haskell distribution for Enterprize Linux (RHEL/CentOS 5 & 6) is now live. The distribution deviates from current practice. When you upgrade to a new Platform from justhub.org you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one. Why? **Stability**: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC 4.1.2 and Binutils 2.17.50.) **Flexibility**: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable. **Sandboxes**: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use **Hubs** instead.) **Package Deletion**: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code. **The Catalogue**: All of the GHC releases can be added as they become available. In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution. But after an upgrade: o any projects configured to work with specific tool chains and libraries will continue undisturbed; o you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out); o even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch. Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating. It might also help new users to make the transition to serious developers more quickly. Thoughts anyone? Chris

1 0

Grok Monad Transformers - some help needed
by Steve Horne 02 Jan '12

02 Jan '12

I'm having another go at figuring out Monad Transformers, starting at the same point I've started and stopped the last couple of times. That's this tutorial... http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html Onion layers, lift etc - I get that. But I've never actually got anything to work - and therefore never built the confidence to move on. Problem 1 - this is literate Haskell. I've tried feeding it to haddock - all I get is an error about it lacking a main. I don't know what to actually do with this after putting it in a *.lhs file. No big deal, but... Problem 2 - even cutting the code out, shoving it in a *.hs file, and :loading it into GHCi, I still get a lot of errors. For the functions test1 and test2, the fixes were explicit type signatures. Easy enough to figure out... test1 :: State Int (Int, Int) test2 :: State String (String, String) I guess the basic issue is the same with test3 (and though I haven't tried the others today, probably test5 and test7 too). The trouble there is that I don't know what those type signatures should be because I don't know that much about monad transformers and how they can work. I can see what's going on in the body of test3, but that is a very small amount of understanding - the type signatures are important. And I can't use :type because GHCi is rejecting the code. In short... HELP!!!

3 3

Dutch FP day 2012, January 6; ; reminder, and happy new year to all of you
by S D Swierstra 02 Jan '12

02 Jan '12

We are happy to announce that the next Dutch functional programming day will take place on January 6, 2012, at the university campus "de Uithof" of Utrecht University. The program, participants registered thus far, and further details can be found at: http://www.cs.uu.nl/wiki/bin/view/FPDag2012/WebHome If you are aware of people who might not be on the mailing list and might be interested (e.g. your students), please point this information out to them. Please do not forget to tell me that you whether you want to go to the dinner too. Best, hoping to see you all, Doaitse

1 0