News aggregator

Brazilian type checking

del.icio.us/haskell - Fri, 05/09/2014 - 1:11am
Categories: Offsite Blogs

Edward Z. Yang: GHC and mutable arrays: a DIRTY little secret

Planet Haskell - Fri, 05/09/2014 - 12:34am

Brandon Simmon recently made a post to the glasgow-haskell-users mailing list asking the following question:

I've been looking into an issue in a library in which as more mutable arrays are allocated, GC dominates (I think I verified this?) and all code gets slower in proportion to the number of mutable arrays that are hanging around.

...to which I replied:

In the current GC design, mutable arrays of pointers are always placed on the mutable list. The mutable list of generations which are not being collected are always traversed; thus, the number of pointer arrays corresponds to a linear overhead for minor GCs.

If you’re coming from a traditional, imperative language, you might find this very surprising: if you paid linear overhead per GC in Java for all the mutable arrays in your system... well, you probably wouldn't use Java ever, for anything. But most Haskell users seem to get by fine; mostly because Haskell encourages immutability, making it rare for one to need lots of mutable pointer arrays.

Of course, when you do need it, it can be a bit painful. We have a GHC bug tracking the issue, and there is some low hanging fruit (a variant of mutable pointer arrays which has more expensive write operation, but which only gets put on the mutable list when you write to it) as well as some promising directions for how to implement card-marking for the heap, which is the strategy that GCs like the JVM's use.

On a more meta-level, implementing a perfomant generational garbage collector for an immutable language is far, far easier than implementing one for a mutable language. This is my personal hypothesis why Go doesn’t have a generational collector yet, and why GHC has such terrible behavior on certain classes of mutation.

Postscript. The title is a pun on the fact that “DIRTY” is used to describe mutable objects which have been written to since the last GC. These objects are part of the remembered set and must be traversed during garbage collection even if they are in an older generation.

Categories: Offsite Blogs

Status of Data Parallel Haskell (DPH)?

Haskell on Reddit - Fri, 05/09/2014 - 12:31am

It seems the development has basically stopped since late 2012. The current version on hackage depends on base ==4.6.* which won't compile on GHC 7.8 either. Is it still being worked on or has all the efforts been transferred to repa now?

submitted by pkmxtw
[link] [7 comments]
Categories: Incoming News

Using mutable array after an unsafeFreezeArray, and GC details

glasgow-user - Fri, 05/09/2014 - 12:18am
I have an unusual application with some unusual performance problems and I'm trying to understand how I might use unsafeFreezeArray to help me, as well as understand in detail what's going on with boxed mutable arrays and GC. I'm using the interface from 'primitive' below. First some basic questions, then a bit more background 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a 2) And what if a do a `cloneMutableArray` on `a` and likewise use the resulting array? Background: I've been looking into an issue [1] in a library in which as more mutable arrays are allocated, GC dominates (I think I verified this?) and all code gets slower in proportion to the number of mutable arrays that are hanging around. I've been trying to understand how this is working internally. I don't quite understand how the "remembered set" works with respect to MutableArray. As best I understand: the remembered set in generation G points to certain objects in older generations, which objects hold references to ob
Categories: Offsite Discussion

Templates as typeclasses?

haskell-cafe - Fri, 05/09/2014 - 12:18am
In going over yet again the many failings of template frameworks for building web apps, I recalled some of the features of the best of the lot, and wondered if those features might be useful in a Haskell template framework. Python's Cheetah tool makes templates almost fully functional members of Python's OO system. A template can inherit from a Python class or another template, and a Python class can inherit from a template. Which makes me wonder if something similar might not be useful in a Haskell template framework. Possibly have each template create an appropriate datatype and make it as an instance of the Template typeclass (and possibly others). Is there already a Haskell web framework that does something like this? Would it actually add value to a framework? Thanks, Mike _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

A Modern History of Lenses (PDF)

del.icio.us/haskell - Thu, 05/08/2014 - 8:08pm
Categories: Offsite Blogs

Categories with different objects

Haskell on Reddit - Thu, 05/08/2014 - 7:41pm

For context, this question was formulated while trying to understand the heart of van laarhoven lenses, particularly the special case of isomorphisms.

In a very simple case, we could have a datatype

Isomorph a b = Iso {view :: a -> b, reView :: b -> a}

but if we try to do (not so) fancy things like

swap = let f (a,b) = (b,a) in Iso f f under (Iso f f') g = f' . g . f simple = under (let f (a,b) = (b,a) in Iso f f) (first show)

we get a type error on 'simple' because the tuple type chances in the middle of the conjugation This is why the full lens type from Control.Lens

Iso s t a b

is useful, it is separately polymorphic in the to/from direction So we could model this like

data Isomorph s t a b = Iso {view :: s -> a, reView :: b -> t}

but this is a datatype, so we can't just compose it with (.) like lenses unless we provide a category instance... but we CAN'T provide a category instance, because Isomorph doesn't have kind (* -> * -> *), though we could provide a perfectly good composition function, it wouldn't be general and would take up namespace.

More generally, the class Category is really only for categories with all haskell types as objects.

I tried something like

class Cat (c :: k) where type Ob c a b iden :: forall x. Ob c x x comp :: forall x y z. Ob c y z -> Ob c x y -> Ob c x z instance Cat Isomorph where type Ob Isomorph (a,a') (b,b') = Isomorph a a' b b' iden = Iso id id

But no matter how I mangle it, it doesn't want to compile. It seems the problem is trying to shove two foralls into one, but foralls aren't first class, so I don't know of any programatic way to do this. Or maybe there is a better way alltogether to represent a category with different objects?

submitted by dogirardo
[link] [8 comments]
Categories: Incoming News

A leak free and tail recursive foldl'

Haskell on Reddit - Thu, 05/08/2014 - 4:28pm
foldl' f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = lgo z' $ seq z' xs where z' = f z x

Are there any reasons why it shouldn't be this?
Note: the original implementation

submitted by mmirman
[link] [25 comments]
Categories: Incoming News

Ghc Compiling Trouble

Haskell on Reddit - Thu, 05/08/2014 - 4:23pm

I'm using ubuntu and emacs to go through LYAHFGG, and no problems, until I got up to the part where you have to compile your programs. $ ghc --make/<filename> $ ./<filename>

Doesn't work, terminal is telling me that it doesn't recognize <$>, or <ghc>, or <.>, or </> and I can't run any of my programs. I've tried to continue, but I can never test out any of my code. Help! I really like the Glascow Haskell Compiler and I need to know how to at least compile my darn programs. Thanks.

submitted by lazilyEVALUATED
[link] [8 comments]
Categories: Incoming News

Compile Time TDD Coverage

Haskell on Reddit - Thu, 05/08/2014 - 4:12pm
Categories: Incoming News

Roman Cheplyaka: Avoid equational function definitions

Planet Haskell - Thu, 05/08/2014 - 3:00pm

One of the first things that Haskell beginners usually notice is that Haskell has this somewhat unusual but attractive way of defining functions case-by-case:

foldr f z [] = z foldr f z (x:xs) = f x (foldr f z xs)

It looks fun and math-y. The other way to do pattern matching, case expressions, is much less advertized, probably because case invokes associations with dirty old imperative programming. Here’s how the same function could be defined using case:

foldr f z l = case l of [] -> z x:xs -> f x (foldr f z xs)

However, there are plenty of reasons to prefer case to multiple function definition clauses.

(If some of these look insignificant at first sight, think of a datatype with tens of constructors, which is quite common when working with abstract syntax trees.)

  1. DRY. Notice how in the equational style the function name and argument names get repeated.

  2. It makes it clear what the function decides upon. The equational style allows you to pattern match on different arguments in different clauses, or even on multiple arguments in the same clause:

    f [] 0 = 0 f _ 1 = 1 f _ _ = 2

    It gives more power, but also makes it harder to see what’s going on. More importantly, even when this additional power is not used, it’s not obvious from the code itself until you eye-scan all the clauses.

  3. It makes code easier to modify or refactor. Tasks like

    • adding or removing a function argument
    • introducing a local definition common for multiple cases
    • preprocessing function arguments or post-processing the function result

    are trivial with the case expression, and hard to impossible (without rewriting or introducing other top-level functions) with clauses.

  4. When profiling, you often want to add an {-# SCC #-} pragma for a function. If the function is written using multiple cases, you need to attach this pragma to every clause separately. Moreover, even if you do so, they won’t account for the evaluation of arguments due to pattern matching in left-hand sides of the equations.

  5. Once you start reading the Core or STG code, writing functions using case makes it much easier to follow the connection between the original source and its intermediate representation.

Perhaps the only reason to have multiple clauses is if you need that additional power of matching on several arguments at the same time, e.g.

Right a <*> Right b = Right (a b) Left a <*> Right _ = Left a Right _ <*> Left b = Left b Left a <*> Left b = Left (a <> b)

You could do this with case by matching on tuples, but it isn’t as nice.

Other than this, I rarely ever define functions in the equational style in my code.

Categories: Offsite Blogs

reactive-banana GLFW-b event register example

haskell-cafe - Thu, 05/08/2014 - 1:08pm
Hello List, I am trying to make the following quasi-code example work: registerMouseButton :: IO (Event MouseButton) registerMouseButton = do(addHandler, fire) <- newAddHandler setMouseButtonCallback $ \button _ -> fire button fromAddHandler addHandler According to http://stackoverflow.com/questions/8631816/reactive-banana-how-to-create-an-addhandlerit looks like it should be something straightforward. Can somebody show an example of a functional code that registers a key or a mouse event? Thanks, Vladimir _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Benefits of coroutine?

Haskell on Reddit - Thu, 05/08/2014 - 8:51am

I found a link(http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topics.html) from haskelllforall.com earlier and am trying to go through the materials in it. I am now reading the corontine article(http://themonadreader.files.wordpress.com/2011/10/issue19.pdf).

I think the article did a good job explaining what corontine is and how it works. However, i don't think i see the full benefits of coroutine from the article.

I know one usage is that you can stream a list of coroutines together as a data process flow. Because you don't need to hold a lot data in memory this way, data is consumed and send to next 'data processor' immediately, low memory footprint is definitely a benefit. Also, because you don't have to put 'data processor's in different threads, so less context switch will happen. The coroutines just cooperate with each other without any locks/mutexes/etc. That can be another benefit.

But don't we lose some parallelism as a result? If we allow more memory usage, and put processors in different threads. Processor 1 can accumulate some data then pass to processor 2, and while processor 2 is at it, processor 1 can continue to process. In fact, this is how java blocking queue is usually used.

Or maybe coroutines can be used to do this, it's just the pipe functions in the article are just simple implementation to help people understand the concept? If this is true, how are those implemented in a real world?

Also, coroutine seems to be useful in many other cases, can someone list those as well?

I know this is a lot questions..but i really want to understand coroutines, they on their own are very interesting already.

submitted by icetortoise
[link] [5 comments]
Categories: Incoming News

Haskell Game Lib Preferences? (SDL/SFML)

Haskell on Reddit - Thu, 05/08/2014 - 7:57am

I'm just starting out learning Haskell, and as I'm primarily a game developer, I figure the best way is to make some games. The most promising bindings appear to be for SDL and SFML.

Is there any consensus as to which of these (or another alternative) is the nicest to use? I don't have any experience with SDL or SFML.

submitted by detorid
[link] [13 comments]
Categories: Incoming News