April 2011 - Haskell-Cafe

SoC project: advice requested
by Gábor Lehel 01 Apr '11

01 Apr '11

Hi all, I would very much like to apply for a Summer of Code project this year; however, I'm having trouble nailing down a project which is both (a) of appropriate scope and (b) which interests and motivates me. There's also obviously the question of needing a mentor for the project. Regarding (b), I'm finding it hard to get really excited about hacking on Cabal or other infrastructure: I'd much rather like to add some kind of new, interesting, and useful capability to GHC itself. Naturally, this comes into a kind of tension with (a). I'd love to work on something type system related, but have the feeling that going from 'amateur Haskeller' to 'type theory and GHC expert' within the course of a single summer is likely going to be too much. (Feel free to correct me on this point, though!) The two projects I've been able to think of which seem like they *might* be appropriate are: integrating the standard 'deriving' mechanism with Template Haskell to support deriving custom classes; and adding native FFI support for passing C structs / tuples (arbitrary products?) of FFI-able types by value, as discussed in [1]. Would either of these be not-too-big / would anyone be willing to mentor them? Alternately, I'd be very happy to receive suggestions about other GHC-related work which would be considered appropriate. (Or, heck, any other compiler.) A related problem is that, having done only minimal GHC hacking so far, drawing up a detailed plan / design in advance as part of the proposal would be difficult. If this is considered necessary and there is someone willing to mentor the project I'd be happy to research the problem in advance of the submission deadline so I can submit a more detailed proposal. Alternately, if it's deemed acceptable to learn the ropes / come up to speed as part of the SoC itself that's fine by me as well. (Wasn't this sort of the point originally?) Background info: I've taken part in the SoC once before, back in 2006 (when I applied to KDE to work on Krita). I don't yet have any Hackage packages to my name, however I'm working on a C++-to-Haskell bindings generator for my bachelor's thesis (the primary target being Qt*) which is likely to spawn quite a few. (I've avoided making any noise about this because I didn't want to put the cart before the horse: the plan was (and still is) to announce something once there is something worth announcing, and it's not at that point quite yet.) Apologies for not writing this email a couple weeks earlier; I have a day job and next to the thesis it didn't leave much time to brainstorm and research. (The job isn't Haskell-related and doesn't even pay as well, so if I get accepted I'll have no compunctions scaling it back (even completely). And the deadline for the thesis is May 15th, which is convenient enough.) Thanks, ~g [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg61034.html * Yes, I know qtHaskell exists. I have some, how to say, 'differences of opinion' with regards to its API, and it's not open source anyways. -- Work is punishment for failing to procrastinate effectively.

3 6

Class constraints for associated type synonyms
by Jan-Willem Maessen 01 Apr '11

01 Apr '11

Hi all - I've been trying to construct a class declaration with an associated type synonym, but I'd like to constrain that type to belong to a particular class. Consider the following class: class Monoid m => Constructs c m | c -> m where construct :: m -> c This captures the idea that the collection c ought to be constructed using the monoid m (say if we're doing the construction using the Writer monad)--the functional dependency indicates the desire for the type c to injectively determine the choice of monoid m. For example: newtype ListBuilder a = Builder ([a] -> [a]) deriving (Monoid) instance Constructs [a] (ListBuilder a) where construct (Builder f) = f [] instance (Ord a) => Constructs (Set a) (Set a) where construct = id Now I'd like to be able to do the same thing using an associated type synonym, something like this: class Monoid (GeneratorOf a) => Generable a where type GeneratorOf a :: * -> * construct :: GeneratorOf a -> a Now, it seems I need FlexibleInstances to do this when I'm using an associated type synonym, but I don't need the flexibility when using a multiparameter type class. In both cases the instance constraint involves types that can be injectively inferred (if I have my terminology straight; work with me here) from a single type mentioned in the class head. In particular, I can imagine storing the dictionary for Monoid (GeneratorOf a) in the dictionary for Generable a, and thus allowing context reduction of (Monoid (GeneratorOf tyvar)) to (Generable tyvar). Meanwhile, I think there are things that are permitted by FlexibleInstances that I'd rather *not* have creeping into my programs. Is there a fundamental constraint I'm missing here that requires the full generality of FlexibleInstances? Do I need to use FlexibleInstances whenever I use associated types in my programs? -Jan-Willem Maessen

3 3

is ppc64 arch registerised
by Jiri Skala 01 Apr '11

01 Apr '11

Hi all, I've read on this page http://hackage.haskell.org/trac/ghc/wiki/Platforms the ppc64 arch is registerised. I succeeded to build ghc-7.0.2 on ppc64 (Fedora) with GhcUnregisterised=YES. Switching off this option currently leads to failure. I'd like to know: - is the info about registerised ppc64 arch still valid? - could you provide me tips how to build it registerised? Thanks Skalnik

1 0

Re: [Haskell-cafe] Strictness is observable
by oleg＠okmij.org 01 Apr '11

01 Apr '11

John Meacham wrote: > Error is not catchable in haskell 98. Only things thrown by raiseIO are. I see; so GHC, absent any LANGUAGE pragma, should have arranged for `error' to generate a non-catchable exception. Still, Haskell98 specifically allows for the behavior that lets us distinguish strict and non-strict functions (that is, the evaluation order in the pure code). Here is the relevant chapter and the verse from Haskell98 (PDF file found on Haskell.org) 21.2.3 File locking Implementations should enforce as far as possible, at least locally to the Haskell process, multiple- reader single-writer locking on files. That is, there may either be many handles on the same file which manage input, or just one handle on the file which manages output. If any open or semi- closed handle is managing a file for output, no new handle can be allocated for that file. If any open or semi-closed handle is managing a file for input, new handles can only be allocated if they do not manage output. Whether two files are the same is implementation-dependent, but they should normally be the same if they have the same absolute path name and neither has been renamed, for example. Warning: the readFile operation (Section 7.1) holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError. The Report specifically warns of the possibility that an implementation that implements file locking, as encouraged by the Report, can distinguish if the entire contents has been consumed or not. The consumption happens in the pure code. Thus the pure Haskell evaluation order starts to matter for a Haskell98-compliant implementation. The following code demonstrates that fact. > -- Haskell98! -- at least as far as GHC implements the absence > -- of LANGUAGE pragmas > -- Strictness is observable > -- With no seq, no unsafe operations > > import System.IO > import Control.Exception > > -- fs and fns are both essentially (const True) functions, > -- but differ in strictness > fs,fns :: Bool -> Bool > > -- non-strict > fns x = True > > -- strict > fs True = True > fs x = True > > -- Any file name that one can create and not be sorry to override > file_name = "/tmp/foo" > > prepare :: IO () > prepare = writeFile file_name "xxx" > > > {- > test f = do > h <- openFile file_name ReadMode > lst <- hGetContents h >>= return . words > ns <- if f (head lst == "") then return "non-strict" else return "" > hClose h > if lst == [] then print ns else print "strict" > -} > > handler :: SomeException -> IO () > handler _ = print "non-strict" > > test f = handle handler $ do > h <- openFile file_name ReadMode > lst <- hGetContents h > ns <- if f (length lst == 0) then return "strict" else return "" > writeFile file_name "" > print ns > > main_s = prepare >> test fs > -- prints "strict" > > main_ns = prepare >> test fns > -- "non-strict" Yves Pare`s wrote: > Then if you turn : > fs True = True > fs x = True > to: > fs x = case x of > True -> True > x' -> True > Is it still strict, or does 'fs' wrap the case test and defer evaluation? Well, we have a test for that, don't we? > fs1 x = case x of > True -> True > x' -> True *Main> prepare >> test fs1 "strict"

2 1

efficient parallel foldMap for lists/sequences
by Sebastian Fischer 01 Apr '11

01 Apr '11

Hello Haskellers, in parallel programs it is a common pattern to accumulate a list of results in parallel using an associative operator. This can be seen as a simple form of the map-reduce pattern where each element of the list is mapped into a monoid before combining the results using `mconcat`. This pattern can be abstracted by the `foldMap` function of the `Foldable` class and we can give a simple parallel implementation using `par` and `pseq`: ~~~ import Data.Monoid import Control.Parallel foldMap :: Monoid m => (a -> m) -> [a] -> m foldMap f [] = mempty foldMap f [x] = f x foldMap f xs = let (ys,zs) = splitAt (length xs `div` 2) xs ys' = foldMap f ys zs' = foldMap f zs in zs' `par` (ys' `pseq` (ys' `mappend` zs')) ~~~ How can this pattern be implemented in Haskell efficiently? I plan to investigate the following options and am interested in previous work. 1. Data.Sequence (from containers) As finger trees are already balanced they look like a good candidate for parallel consumption. However, the current implementation of the `Foldable` instance is sequential. I wonder what would be the overhead and how it could be reduced if it is is too large. I think, I would first go for an implementation outside of `Foldable` and later consider the overhead of overloading. 2. Data.Array.Repa (from repa) provides a `map` and (sequential) `fold` functions. I think that the main advantage of repa is fusion of successive traversals which is not necessary for the pattern in question. Hence, I'm not sure whether it's a good candidate for the job. Also I don't know how to implement the pattern using repa. Can it be done using `slice` or should it be done by changing repa itself? 3. Data.Monoid.Reducer (from monoids) `foldMapReduce` looks promising. I wonder whether it could be used for parallel reduction and how efficient it would be. Which approach do you think is most promising? What other options are there? Best, Sebastian

1 0

Strictness is observable
by oleg＠okmij.org 01 Apr '11

01 Apr '11

Daniel Fischer wrote: > If you have a strict function, you may evaluate its argument eagerly > without changing the result^1, while eager evaluation of a non-strict > function's argument may produce _|_ where deferred evaluation wouldn't. Sadly, that is quite untrue. Strictness is observable, already in Haskell98. That distressing result has nothing to do with imprecise exceptions, seq, non-termination, lack of resources, or the use of unsafe features. Plainly, just by changing the strictness of a function one may cause the program to print different results, such as "strict" or "non-strict" in the code below. -- Haskell98! -- Strictness is observable -- With no seq, no unsafe operations import Control.Exception -- fs and fns are both essentially (const True) functions, -- but differ in strictness fs,fns :: Bool -> Bool -- non-strict fns x = True -- strict fs True = True fs x = True handler :: SomeException -> IO () handler _ = print "strict" test f = handle handler $ if f (error "Bang!") then print "non-strict" else return () main_s = test fs -- prints "strict" main_ns = test fns -- prints "non-strict"

3 3

Re: [Haskell-cafe] Strictness is observable
by John Meacham 01 Apr '11

01 Apr '11

Error is not catchable in haskell 98. Only things thrown by raiseIO are. On Apr 1, 2011 12:02 AM, <oleg(a)okmij.org> wrote:

1 0

A maintenance command of Haskell cabal packages
by Kazu Yamamoto 01 Apr '11

01 Apr '11

Hello cafe, Let me announce a maintenance command of Haskell cabal packages. http://www.mew.org/~kazu/proj/cab/en/ ---- "cab" is a MacPorts-like maintenance command of Haskell cabal packages. Some part of this program is a wrapper to "ghc-pkg" and "cabal". If you are always confused due to inconsistency of two commands, or if you want a way to check all outdated packages, or if you want a way to remove outdated packages recursively, this command helps you. ---- I'm a user of Yesod. Yesod consists of many packages and they are being updated very quickly. So, I need this command. Regards, --Kazu

5 8