Hashtables, a new Haskell library for fast mutable hash tables | Hacker News Reader

Hashtables, a new Haskell library for fast mutable hash tables

gregorycollins.net

70 pointsT_S_10 comments

mutability in Haskell? I thought Haskell was purely functional i.e. lazy and immutablility are foundational. Can someone clarify please?

That's the default. There are, however, many other interesting computational environments you might want to use, which Haskell let's you enable: controlled, strict evaluation (the use of seq and rnf); local mutable state (the `ST` monad); mutable state with transactions and rollbacks (the `STM` monad); arbitrary effects on the world (the `IO` monad); computations with backtracking (the `Logic` monad); deterministic parallelism with shared state (the `Par` monad) and so on.

Just remember: in Haskell, persistent and immutable is the default. You turn on other environments as you need them.

Why is it the default? So-called "purely functional" programming is a rich, safe, environment for most programming problems, and makes lots of nice things possible, such as trivial parallelization, automatic thread safety, proofs on code via simple equational reasoning, and powerful optimizations.

Too bad they made lazy the default.

care to elaborate?

Haskell is the only widely used language that uses lazy evaluation by default. This has historically lead to confusion and difficulties with reasoning about time and space, particularly when a programmer is coming from a strict language.

Why do we care about laziness by default? Like purity, it adds power and expressiveness.

----

Finally, what would a strict Haskell be like? Here's a discussion: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev... )

Space leaks.

Also, unpredictable program behavior (which nearly destroys its usefulness in embedded beyond what perhaps Galois has been doing).

For what is worth, Edward Yang is writing an excellent series on space leaks in Haskell:

http://blog.ezyang.com/2011/05/space-leak-zoo/

The series require Haskell knowledge but this summary is fairly readable if you have a good grounding on programming language theory and implementation.

Thank you for a thorough overview.

Haskell doesn't prevent side effects. Otherwise, you wouldn't be able to do I/O. Instead, Haskell requires you to be explicit about side effects through Monads.

I think about it this way: imperative languages allow side effects by default, but allow you to write side-effect free code. Purely functional languages don't use side-effects by default, but allow you to write code with side-effects.

You can escape the purely functional part (to do IO for example). This library does however provide 2 implementations: one in the IO monad and one in the ST monad.

If you use the IO monad one then you can do whatever side effects you want. It's up to you to use the rest of the code in a responsible way (which means that you can write code C style if you want).

The ST monad version is quite nice, it lets you use the hash table as if it was modifiable, but only inside the ST monad. Looking at it from the outside, it's still purely functional, and within the ST monad you're restricted to purely functional programming and the facilities provided by the ST monad. This makes it a safe alternative when you want to use a hash table for performance reasons but still want to limit what side effects that can be used.

Reply on news.ycombinator.com