# News aggregator

### An alternative Haskell home page

### An alternative Haskell home page

### Eric Kidd: Deploying Rust applications to Heroku, with example code for Rustful

If you have git and the Heroku toolbelt on your system, this should be easy:

git clone https://github.com/emk/heroku-rust-hello.git cd heroku-rust-hello heroku create --buildpack https://github.com/emk/heroku-buildpack-rust.git git push heroku masterIf you want to create your own Rust web server from scratch, keep reading. But fair warning: Rust is not yet ready for serious web development.

### Architecture of a Real World Haskell Application II

Not exactly about the architecture anymore, but focuses now on the transport protocol parsing, especially on the historical evolution of it: Architecture of a Real World Haskell Application II. I am quite busy currently, so it took some time and had not so much time editing the post. So if you find errors, that's expected :)

submitted by empowerg[link] [2 comments]

### Prime factors of a given number using list comprehension

Hi, how can I find prime factors of a given number using list comprehension in Haskell? Can you help me? Thank you in advance.

submitted by shevchenko7[link] [11 comments]

### Pandoc: HOWTO for ePub -> PDF conversion?

I'm looking for a handy way to convert an EPUB format document to something else. The immediate goal is PDF (sadly: PDF readers on Linux are superior to ePub readers), but others might also be considered. Hrm.... Actually, LaTeX would solve most of my problems....

I'm only partially familar with EPUB formats, and virtually not at all with Haskell.

I've unzipped the epub and have my document tree:

. ├── META-INF └── OEBPS ├── css ├── fonts └── imagesWhat I'm looking for is a convenient way to arrange the contents such that they're output in the form of the book I'd like. This comprises a bunch of chapters, several parts, and front- and end-matter, as well as images. Slightly more than are convenient to hand-edit.

There's a package.ocf file which is the manifest. Parsing that properly would work for me. Are there tools which provide for this?

And if there's a better place on reddit for pandoc questions, please say.

Thanks.

UpdateNot fully converted, but I'm pretty much there.

I used a shell loop and pandoc to create LaTeX files for each HTML source from the exploded ePub tree.

I used a LaTeX book template to modify the package.ocf file using \include{} statements to recreate the document structure.

pdflatex works on that to output PDF (including not complaining about JPEG image sizes as latex itself did).

I've had to fix up a few bits of the LaTeX, including changing the subscript encoding and including a few additional LaTeX packages to make everything tidy. Section naming was a bit wonky and I've fixed that ... except for some end-mater materials. I need to figure out how to include the cover image as an actual cover. And probably (re)-generate an index.

But I've got 526 pages of very nicely laid out text.

submitted by dredmorbius[link] [6 comments]

### What is a good, achievable project (weekend project) in haskell that will teach me good functional practices as well as some cool haskell tricks?

I'm not really looking for a tutorial or something that's going to hold my hand. I'm looking for a project that I can sink my teeth into and struggle with in order to better know the language as well as functional programming.

submitted by billofalltrades[link] [45 comments]

### Eric Kidd: Installing Rust nightly builds on Ubuntu 10.04 Lucid

Rust is a systems programming language designed around speed and safety. It sits roughly halfway between Go and Haskell. In particular, it combines precise, safe control over memory with high-level functional programming. Haskell programmers, for example, will notice that Rust's and_then works much like bind in Haskell's Maybe monad:

use std::os::getenv; use std::io::net::ip::Port; /// Look up our server port number in PORT. fn get_server_port() -> Port { getenv("PORT") .and_then(|s| from_str::<Port>(s.as_slice())) .unwrap_or(8080) }Anyway, I spent this morning trying to get Rust working on Ubuntu 10.04 Lucid, as part of a larger effort to deploy a Rust application on Heroku. (More on that soon.) On Ubuntu 10.04, rustc fails looking for libstdc++.so.6:

### ghc-rts.pdf

### An alternative Haskell home page

### Exceptions in continuation-based monads

### elm-shadertoy: GLSL quasiquotes for plasma, fire, raymarching effects in web GL in Elm (demo)

### Yesod Web Framework: Exceptions in continuation-based monads

I've been meaning to write a blog post for a few weeks now about exception
handling in Haskell, especially with regards to monad transformer stacks.
Unfortunately, this is *not* that blog post, just one small aspect of it:
exception handling in continuation-base monads.

I've seen many people at different times advocate having some kind of exception handling in continuation-based monads. Without calling out individual instances, I'll sum up a lot of what I've discussed as, "Why can't conduit/enumerator/pipes have a bracket function?"

After noticing yet another request for such a thing this morning, I decided to write up a quick demonstration of what happens when you create a bracket function for the enumerator package. I'll be using MonadCatchIO-transformers (which is thankfully deprecated in favor of the exceptions package), and snap-core's orphan instance.

Let's start off by noticing something interesting: enumerator provides an enumFile function (for reading the contents of a file), but no iterFile equivalent to write data back. Using a bracket, it's actually really easy to write up such a function (including some debug output to make sure we're being safe):

iterFile :: (MonadCatchIO m, MonadIO m, Functor m) => FilePath -> Iteratee ByteString m () iterFile fp = bracket (liftIO $ do putStrLn $ "opening file for writing: " ++ fp IO.openFile fp IO.WriteMode) (\h -> liftIO $ do putStrLn $ "closing file for writing: " ++ fp IO.hClose h) iterHandleThere shouldn't be any surprises in this implementation: we open a file handle in the acquire argument, close that handle in the release argument, and then use the handle in the inner argument. All is well in the world. Now let's try actually using this function, both with and without exceptions being thrown:

main :: IO () main = do writeFile "exists.txt" "this file exists" run (enumFile "exists.txt" $$ iterFile "output1.txt") >>= print run (enumFile "does-not-exist.txt" $$ iterFile "output2.txt") >>= printOr you can try running the code yourself. Let's look at the output:

opening file for writing: output1.txt closing file for writing: output1.txt Right () opening file for writing: output2.txt Left does-not-exist.txt: openBinaryFile: does not exist (No such file or directory)Notice that the output2.txt Handle is *never closed*. This is inherent to
working with any continuation based monad, since there are no guarantees that
the continuation will be called at all. It's *also* impossible to know if your
continuation will be called only once. With something like ContT, it's
possible to have the continuation run multiple times, in which case your
cleanup actions can run multiple times, which can be really
bad.

The exceptions package handles this in the right way. There are two different
type classes:
MonadCatch
allows for *catching* exceptions (which a continuation based monad *does* allow
for), whereas
MonadMask
gives guarantees about bracket/finally semantics, which is what a
continuation-based monad *cannot* do. Another valid approach is
monad-control, which makes
it (I believe) impossible to write invalid instances.

(I want to get into more of the details of the trade-offs between exceptions and monad-control, but that will have to wait for another blog post. For now, I just wanted to address immediate continuation based concern.)

If you're in a continuation based monad and you need exception safe resource
handling, there *is* a solution:
resourcet.
resourcet hoists the exception safety outside of the realm of the continuation
based code, and maintainers finalizer functions via mutable variables. Note
that this isn't just useful for continuation based monads, but for any
situation where you don't have full control over the flow of execution of the
program. For example, you'd use the same technique for an io-streams directory
traversal.

One last caveat. There *is* one case where a continuation based monad could in
theory have a valid bracket function, which is where you have full knowledge
of the code which will run the continuation, and can guarantee that all
continuations will always be executed. So if you hide constructors and only
expose such run functions, you might be safe. But the burden of proof is on
you.

Note: I'm purposely *not* linking to any of the conversations I've referred to
about getting a bracket function for continuation based monads, I don't feel
like calling people out here. Also, in case you don't feel like loading up the
School of Haskell page, here's the full source code for my example above:

### Curious (with a bit of beginner ranting) about some of the error messages from ghc

I'm following along with Justin Le's wonderful article about functors and monads. Now that I know a little more than I did yesterday (

### Theory Lunch (Institute of Cybernetics, Tallinn): Playing with a beautiful mind

Today’s talk’s topic is an idea so important in game theory, and with so many applications in different fields including computer science, that it earned its discoverer, together with Reinhard Selten and John Harsanyi, the 1994 Nobel Memorial Prize in Economic Sciences.

To introduce this idea, together with other basic game-theoretic notions, we resort to some examples. Here goes the first one:

Alice and Bob are planning an evening at the cinema. Alice would like to watch the romantic movie, while Bob would like to watch the action movie. Neither of them likes much the other’s favored movie: however, should they split, the sadness for being alone would be so big, that neither of them would enjoy his or her movie!

This is the kind of situation modeled by a *game in normal form*, where we have:

- A set of
*players*. - A set of
*strategies*for each player. - A collection of
*utility functions*which associate to each*strategic profile*a real number, such that is the*utility*player gets from the strategic profile .

In the case of Alice and Bob, this may be summarized with a table such as the following:

Romantic Action Romantic ActionSuch tables represent games in normal form between two players, where the *rows* of the table are labeled with the strategies suitable for the *first* player, and the *columns* of the table are labeled with the strategies suitable for the *second* player: the entries of the table indicate the values of the utility functions when the first player plays the corresponding row and the second player plays the corresponding column. When we want to emphasize the role of player in contrast to the others, we write as , and talk about the strategy of player *given* the strategic profile of the other players.

Suppose that Alice is the first player, and Bob is the second player: then the table tells us that, if they both choose the romantic movie, Alice will enjoy it a lot (utility value ) and Bob not very much (utility value ). However, if Bob *defects* from this strategic profile and goes watch the action movie, he will ultimately not enjoy it, because he will be sad for not being together with Alice—which was the entire point about organizing the evening at the movies!

Let us consider another game (a rather serious one indeed) where the players are a lion and a gazelle. The lion wants to catch the gazelle; the gazelle wants to avoid being caught by the lion. To do this, they may choose between being on the move, or staying more or less in the same place. It turns out, from observation in the field, that the table for the lion-and-gazelle situation is similar to the one below:

Move Stay Move StayWe observe that, for the lion, the most profitable strategy is to move. Indeed, if the gazelle moves, then the utility for the lion is if he moves, which is more than the he gets if he stays; on the other hand, if the gazelle stays, then the utility for the lion is if he moves, which is more than the he gets if he stays. A strategy such as this, which always gives the *best* possible result *independently* of the other players’ strategies, is called a *dominant strategy*. Such strategies are indeed quite rare: indeed, neither Alice nor Bob from the previous game had a dominant strategy, nor has the gazelle here, as they can maximize their own profit only by choosing the *same* strategy as the other player.

So, what if we relax the requirement, and just demand that every player chooses the most favorable strategy, *given* the strategies of the other players? This is the basic intuition under the concept of Nash equilibrium, formalized and studied by John Nash in his 1950 doctoral thesis.

**Definition 1.** A *Nash equilibrium* for a game in normal form is a strategic profile such that, for every player and every strategy feasible for player , it is the case that .

The situation when both the lion and the gazelle are on the move, is a Nash equilibrium: and is the only Nash equilibrium in the corresponding game. (By definition, every dominant strategy enters every Nash equilibrium.) The situation when both Alice and Bob go watch the romantic movie, is a Nash equilibrium: and so is the one when they go watch the action movie.

So, does every game have a Nash equilibrium?

Actually, no.

Indeed, suppose that the predator and the prey, instead of being large mammals such as the lion and the gazelle, are small insects such as a dragonfly and a mosquito. It then turns out, after careful observation, that the table for the predator-prey game gets more similar to the following:

Move Stay Move StayIn this situation, the dragonfly maximizes its utility if it does the *same* as the mosquito. In turn, however, the mosquito maximizes its own utility if it does the *opposite* than the dragonfly! In such a situation there can be no such thing as a Nash equilibrium as defined above.

Where determinism fails, however, randomization may help.

**Definition 2.** A *mixed strategy* for the player in a game in normal form is a probability distribution on the space of the strategies for player . A *mixed strategy profile* is a collection of mixed strategies for each player.

For example, the dragonfly might decide to move with probability , and stay still with probability ; similarly, the mosquito might decide to move with probability , and stay still with probability .

With mixed strategies, the important value for player to take into account is the *expected utility given the strategic profile*

which we may write when we want to emphasize the role of player .

Now, suppose that the dragonfly decides to set its own paramenter so that its expected utility does not change if the mosquito decides to move or to stay: this corresponds to the dragonfly maximizing its expected utility, given the mixed strategy of the mosquito. Our table tells us that this corresponds to

which has solution . In turn, if the mosquito sets its own parameter so that its own expected utility does not change if the dragonfly decides to move or stay, then

which has solution . The situation where the dragonfly moves with probability and the mosquito moves with probability is a situation none of the two insects has any advantage to change on its own part, given the choice of the other.

**Definition 3.** A *mixed strategy Nash equilibrium* for a game in normal form is a mixed strategy profile such that, for every player and every mixed strategy feasible for player , it is the case that .

And here comes Nash’s great result:

**Nash’s theorem.** Every game in normal form that allows at most finitely many *pure* strategic profiles admits at least one, *possibly mixed* strategy, Nash equilibrium.

It is actually sufficient to prove Nash’s theorem (as he did in his doctoral thesis) when there are only many players, and each of them only has finitely many pure strategies: such limitation is only apparent, because the condition that pure strategy profiles are finitely many means that all players have finitely many pure strategies, and at most finitely many of them have more than one.

The idea of the proof, which we might go through in a future Theory Lunch talk, goes as follows:

- Identify the space of mixed strategic profiles with a compact and convex set for suitable .
- For define a family of continuous transformations .
- By the Brouwer fixed-point theorem, for every there exists a mixed strategic profile such that .
- As is compact, the sequence has a limit point .
- By supposing that is not a mixed strategy Nash equilibrium we reach a contradiction.

We remark that Nash equilibria are not optimal solutions: they are, at most, *lesser evils for everyone given the circumstances*. To better explain this we illustrate a classic problem in decision theory, called the *prisoner’s dilemma*. The police has arrested two people, who are suspects in a bank robbery: however, the only evidence is about carrying firearms without license, which is a minor crime leading to a sentence of one year, compared to the ten years for bank robbery. So, while interrogating each suspect, they propose a bargain: if the person will testify against the other person for bank robbery, the police will drop the charges for carrying firearms without license. The table for the prisoner’s dilemma thus has the following form:

Then the situation where both suspects testify against each other is the only pure strategy Nash equilibrium: however, it is very far from being optimal…

### Hiring: Haskell data analysis app developer, work from anywhere (telecommute)

Are you experienced at delivering high-quality apps? Are you interested in data analysis, pattern detection, optimization, machine learning? Do you like working on numerous, diverse projects with quick timelines? Do you write well-structured code that other people would like to pick up, learn from, and reuse? And -- of course -- do you love functional programming?

FP Complete is hiring a Haskell data analysis application developer to work on numerous compact applications and libraries that will be used, learned from, and reused by our customers to understand critical data in a timely way. The focus is on financial markets (such as equities trading), so experience with that subject is strongly desired and will work in your favor. We also do significant scientific work. Typical tasks will range from a few days to a few months in duration.

You can work from home, anywhere in the world, as long as you are available 30+ hours a week, on a schedule compatible with Eastern USA colleagues. You have to be organized and good at working with limited supervision, from understanding requirements to design, implementation, test, delivery, and versioning with iterative improvements. You must be an experienced functional programmer in Haskell or another FP language, with sample code to show.

Extra good if you understand HPC, linear algebra, statistics, and/or team software engineering methods, or have contributed significantly to libraries or other open-source projects. Also great if you have experience dealing with end users and/or creating training materials. And if you can start soon!

I’m the founder and head of FP Complete, the Haskell tools & services company. Join our team and stay with us as we grow. Email your resume/C.V., compensation requirements, descriptions of some of your impressive accomplishments, and some links to good FP source code written personally by you, to me at jobs@fpcomplete.com . Applicants for previous openings are welcome to apply again. For this position we will accept applications from highly experienced candidates, as well as highly motivated less senior candidates who can show they have the skills and are ready to work. This is a long-term contractor position.

Questions, feel free to email or PM me. Thanks. It is a pleasure to be a part of such a great community.

submitted by FPguy[link] [4 comments]