# News aggregator

### Edward Z. Yang: Parsec: “try a <|> b” considered harmful

*tl;dr The scope of backtracking try should be minimized, usually by placing it inside the definition of a parser.*

Have you ever written a Parsec parser and gotten a really uninformative error message?

"test.txt" (line 15, column 7): unexpected 'A' expecting end of inputThe line and the column are randomly somewhere in your document, and you're pretty sure you should be in the middle of some stack of parser combinators. But wait! Parsec has somehow concluded that the document should be ending immediately. You noodle around and furthermore discover that the true error is some ways *after* the actually reported line and column.

You think, “No wonder Parsec gets such a bad rep about its error handling.”

Assuming that your grammar in question is not too weird, there is usually a simple explanation for an error message like this: the programmer sprinkled their code with too many backtracking try statements, and the backtracking has destroyed useful error state. In effect, at some point the parser failed for the reason we wanted to report to the user, but an enclosing try statement forced the parser to backtrack and try another (futile possibility).

This can be illustrated by way of an example. A Haskeller is playing around with parse combinators and decides to test out their parsing skills by writing a parser for Haskell module imports:

stmt ::= import qualified A as B | import APiggy-backing off of Parsec’s built in token combinators (and the sample code), their first version might look something like this:

import Text.Parsec import qualified Text.Parsec.Token as P import Text.Parsec.Language (haskellDef) data Stmt = QualifiedImport String String | Import String deriving (Show) pStmt = pQualifiedImport <|> pImport pQualifiedImport = do reserved "import" reserved "qualified" i <- identifier reserved "as" i' <- identifier return (QualifiedImport i i') pImport = do reserved "import" i <- identifier return (Import i) lexer = P.makeTokenParser (haskellDef { P.reservedNames = P.reservedNames haskellDef ++ ["qualified", "as"] }) identifier = P.identifier lexer reserved = P.reserved lexer parseStmt input = parse (pStmt >> eof) "(unknown)" inputUnfortunately, the parser doesn't work for regular imports—they get this error message:

*Main> parseStmt "import Foo" Left "(unknown)" (line 1, column 8): unexpected "F" expecting "qualified"After a little Googling, they discover that Parsec doesn’t backtrack by default. Well, that’s fine; why not just insert a try into the parser.

pStmt = try pQualifiedImport <|> pImportThis fixes both parses and suggests the following rule for writing future parsers:

If I need choice over multiple parsers, but some of these parsers might consume input, I better tack a try onto each of the parsers, so that I can backtrack.Unbeknownst to the user, they have introduced bad error reporting behavior:

*Main> parseStmt "import qualified Foo s B" Left "(unknown)" (line 1, column 17): unexpected reserved word "qualified" expecting letter or digit or "#"Wait a second! The error we wanted was that there was an unexpected identifier s, when we were expecting as. But instead of reporting an error when this occurred, Parsec instead *backtracked*, and attempted to match the pImport rule, only failing once that rule failed. By then, the knowledge that one of our choice branches failed had been forever lost.

How can we fix it? The problem is that our code backtracks when we, the developer, know it will be futile. In particular, once we have parsed import qualified, we know that the statement is, in fact, a qualified import, and we shouldn’t backtrack anymore. How can we get Parsec to understand this? Simple: *reduce the scope of the try backtracking operator:*

Here, we have moved the try from pStmt into pQualifiedImport, and we only backtrack if import qualified fails to parse. Once it parses, we consume those tokens and we are now committed to the choice of a qualified import. The error messages get correspondingly better:

*Main> parseStmt "import qualified Foo s F" Left "(unknown)" (line 1, column 22): unexpected "s" expecting "as"The moral of the story: The scope of backtracking try should be minimized, usually by placing it inside the definition of a parser. Some amount of cleverness is required: you have to be able to identify how much lookahead is necessary to commit to a branch, which generally depends on *how* the parser is used. Fortunately, many languages are constructed specifically so that the necessary lookahead is not too large, and for the types of projects I might use Parsec for, I’d be happy to sacrifice this modularity.

Another way of looking at this fiasco is that Parsec is at fault: it shouldn’t offer an API that makes it so easy to mess up error messages—why can’t it automatically figure out what the necessary lookahead is? While a traditional parser generator can achieve this (and improve efficiency by avoiding backtracking altogether in our earlier example), there are some fundamental reasons why Parsec (and monadic parser combinator libraries like it) cannot automatically determine what the lookahead needs to be. This is one of the reasons (among many) why many Haskellers prefer faster parsers which simply don’t try to do any error handling at all.

Why, then, did I write this post in the first place? There is still a substantial amount of documentation recommending the use of Parsec, and a beginning Haskeller is more likely than not going to implement their first parser in Parsec. And if someone is going to write a Parsec parser, you might as well spend a little time to limit your backtracking: it can make working with Parsec parsers a *lot* more pleasant.

### My first "real" Haskell program - how am I doing?

It's compiler from MiniJava to MIPS: https://github.com/chrismwendt/MiniJava

This compiler is modeled after the one we wrote in compilers class in Java. I had been itching to give it a shot in Haskell but couldn't muster the confidence to dive in until a few weeks ago.

I have probably spent on the order of a few hundred hours learning and programming in Haskell, starting out with some of the 99 Haskell and moving on to complete roughly 70 Project Euler problems. This is my first Haskell program which is over 100 lines, and I'm pretty happy with the result but I would love to get feedback from more experienced Haskellers.

I really tried to branch out from what I was familiar with and use appropriate packages like parsec, lens, fgl, disjoint-set, monad transformers, and applicative style. Let me know how I'm doing =)

submitted by Total_1mmersion[link] [7 comments]

### New with haskell. Fixing a stack space overflow? And making code faster and/or more idiomatic in general?

I got the code for modular exponentiation from Rosetta Code, and it does work with toy cases. I'm trying a bigger case out now and while I don't see how something so lazy is running out of stack space, it managed to do so.

So the code is as follows. I tried to stay away from loops and go with what functionally I would do, but still use the "take 2" because I only need one result from a list of a ton of results, and I know that once it finds the second result it will terminate. The comments in the annotation explain what I'm trying to do, but editing and fixing it up there is helpful. Don't feel too bad about helping me here since this is derived from an assignment for a math class not related to haskell working on a problem we were never asked to tackle. If it makes any difference, I already know I passed the math class and this code won't be useful for people taking the class in the future unless they know enough about the problem to make using this code overkill.

Code pasted here, annotation of my thoughts in comments on bottom: http://lpaste.net/104249

So any help on not using up so much stack space (I really don't know why it is using more than the bare minimum to be honest) would be appreciated, as well as comments on general coding style since this is a way I can play with the arbitrary math in Haskell as part of a larger goal of learning haskell and adding it to my toolbox of languages. The problem seemed well suited for a functional language, as well as a fast one.

Speaking of fast: I notice that even when I compile with -O2 and -threaded and tell it to use 4 threads (or 8, but I'm on a 4 core processor) it does use all the cores, but only about 30 percent max on each. I get more performance than using 1 core would give me, but if I can get 100% utilization of even 3 of the 4 cores (i.e. at least 300% of my cpu, instead of the 120% I can get right now) I would be happy. Do you know what is "wasting" cpu cycles and stopping it from fully utilizing the CPU?

Thanks in advance for any help! If anyone here knows D, I am trying it with BigInt too, but even though D does offer simpler parallelism than other languages in the class, it still seems rough around the edges. Besides, using std.range.iota to parallelize testing each number doesn't let me use BigInt, so it might be a useless exercise there.

Any tips on the math (Only test odd numbers, if you have a proof that there are no even answers for example) are useful too but I'm mostly looking for help on the stack space issue and general coding style tips.

Thanks!

EDIT: News from an 8 core CPU (with more memory as well): I haven't hit run out of stack space yet, but I still am only getting 30% usage overall (this time 1 core is not 100%, all 8 cores all) so even though I see it running with 8 threads, each CPU is giving me at most 25% utilization at any point in time, and is often only 15%.

EDIT 2: Forgot to knock on wood, ran out of stack space on the 8 core machine too. I would wonder if giving it all 16 gigs would do better than only 8, but the bigger question is what is even using 8 gigs to begin with?

submitted by maccam912[link] [25 comments]

### hs2bf commentary

### Was directed here for help with why ghc is failingto find mtl.

### Installing tidal-vis is hard

### [Pluralsight] Haskell Fundamentals Part 1 [2013, ENG] :: RuTracker.org (ex torrents.ru)

### What Features Would You Like to Find in a Haskell IDE?

In case the community decides to build a Haskell editor/IDE from scratch, how do you imagine its layout design? What particular features you want to find in it? How do you imagining the debugging procedure being handled with the tool? ...

In case you are comfortable with an existing tool, would you share your configurations so others can benefit from it.

submitted by BanX[link] [88 comments]

### Research position "Coalgebraic Logic Programming forType Inference"

### Dan Piponi (sigfpe): Types, and two approaches to problem solving

SubproblemsConsider sorting algorithms. A large class of sorting algorithms, including quicksort, break a sequence of values into two pieces. The two pieces are smaller so they are easier to sort. We sort those pieces and then combine them, using some kind of merge operation, to give an ordered version of the original sequence. Breaking things down into subproblems is ubiquitous and is useful far outside of mathematics and computing: in cooking, in finding our path from A to B, in learning the contents of a book. So I don’t need to say much more here.

Quotient problemsThe term quotient is a technical term from mathematics. But I want to use the term loosely to mean something like this: a quotient problem is what a problem looks like if you wear a certain kind of filter over your eyes. The filter hides some aspect of the problem that simplifies it. You solve the simplified problem and then take off the filter. You now ‘lift’ the solution of the simplified problem to a solution to the full problem. The catch is that your filter needs to match your problem so I’ll start by giving an example where the filter doesn’t work.

Suppose we want to add a list of integers, say: 123, 423, 934, 114. We can try simplifying this problem by wearing a filter that makes numbers fuzzy so we can’t distinguish numbers that differ by less than 10. When we wear this filter 123 looks like 120, 423 looks like 420, 934 looks like 930 and 114 looks like 110. So we can try adding 120+420+930+110. This is a simplified problem and in fact this is a common technique to get approximate answers via mental arithmetic. We get 1580. We might hope that when wearing our filters, 1580 looks like the correct answer. But it doesn’t. The correct answer is 1594. This filter doesn’t respect addition in the sense that if a looks like a’ and b looks like b’ it doesn’t follow that a+b looks like a’+b’.

To solve a problem via quotient problems we usually need to find a filter that does respect the original problem. So let’s wear a different filter that allows us just to see the last digit of a number. Our original problem now looks like summing the list 3, 3, 4, 4. We get 4. This is the correct last digit. If we now try a filter that allows us to see just the last two digits we see that summing 23, 23, 34, 14 does in fact give the correct last two digits. This is why the standard elementary school algorithms for addition and multiplication work through the digits from right to left: at each stage we’re solving a quotient problem but the filter only respects the original problem if it allows us to see the digits to the right of some point, not digits to the left. This filter does respect addition in the sense that if a looks like a’ and b looks like b’ then a+b looks like a’+b’.

Another example of the quotient approach is to look at the knight’s tour problem in the case where two opposite corners have been removed from the chessboard. A knight’s tour is a sequence of knight’s moves that visit each square on a board exactly once. If we remove opposite corners of the chessboard, there is no knight’s tour of the remaining 62 squares. How can we prove this? If you don’t see the trick you can get get caught up in all kinds of complicated reasoning. So now put on a filter that removes your ability to see the spatial relationships between the squares so you can only see the colours of the squares. This respects the original problem in the sense that a knight’s move goes from a black square to a white square, or from a white square to a black square. The filter doesn’t stop us seeing this. But now it’s easier to see that there are two more squares of one colour than the other and so no knight’s tour is possible. We didn’t need to be able to see the spatial relationships at all.

(Note that this is the same trick as we use for arithmetic, though it’s not immediately obvious. If we think of the spatial position of a square as being given by a pair of integers (x, y), then the colour is given by x+y modulo 2. In other words, by the last digit of x+y written in binary. So it’s just the see-only-digits-on-the-right filter at work again.)

Wearing filters while programmingSo now think about developing some code in a dynamic language like Python. Suppose we execute the line:

**a = 1**

The Python interpreter doesn’t just store the integer 1 somewhere in memory. It also stores a tag indicating that the data is to be interpreted as an integer. When you come to execute the line:

**b = a+1**

it will first examine the tag in a indicating its type, in this case int, and use that to determine what the type for b should be.

Now suppose we wear a filter that allows us to see the tag indicating the type of some data, but not the data itself. Can we still reason about what our program does?

In many cases we can. For example we can, in principle, deduce the type of

**a+b*(c+1)/(2+d)**

if we know the types of

**a**,

**b**,

**c**,

**d**. (As I’ve said once before, it’s hard to make any reliable statement about a bit of Python code so let's suppose that

**a**,

**b**,

**c**and

**d**are all either of type int or type float.) We can read and understand quite a bit of Python code wearing this filter. But it’s easy to go wrong. For example consider

**if a>1 then:**

**return 1.0**

**else:**

**return 1**

The type of the result depends on the value of the variable a. So if we’re wearing the filter that hides the data, then we can’t predict what this snippet of code does. When we run it, it might return an int sometimes and a float other times, and we won’t be able to see what made the difference.

In a statically typed language you can predict the type of an expression knowing the type of its parts. This means you can reason reliably about code while wearing the hide-the-value filter. This means that almost any programming problem can be split into two parts: a quotient problem where you forget about the values, and then problem of lifting a solution to the quotient problem to a solution to the full problem. Or to put that in more conventional language: designing your data and function types, and then implementing the code that fits those types.

I chose to make the contrast between dynamic and static languages just to make the ideas clear but actually you can happily use similar reasoning for both types of language. Compilers for statically typed languages, give you a lot of assistance if you choose to solve your programming problems this way.

A good example of this at work is given in Haskell. If you're writing a compiler, say, you might want to represent a piece of code as an abstract syntax tree, and implement algorithms that recurse through the tree. In Haskell the type system is strong enough that once you’ve defined the tree type the form of the recursion algorithms is often more or less given. In fact, it can be tricky to implement tree recursion incorrectly and have the code compile without errors. Solving the quotient problem of getting the types right gets you much of the way towards solving the full problem.

And that’s my main point: types aren’t simply a restriction mechanism to help you avoid making mistakes. Instead they are a way to reduce some complex programming problems to simpler ones. But the simpler problem isn’t a subproblem, it’s a quotient problem.Dependent typesDependently typed languages give you even more flexibility with what filters you wear. They allow you to mix up values and types. For example both C++ and Agda (to pick an unlikely pair) allow you to wear filters that hide the values of elements in your arrays while allowing you to see the length of your arrays. This makes it easier to concentrate on some aspects of your problem while completely ignoring others.

NotesI wrote the first draft of this a couple of years ago but never published it. I was motivated to post by a discussion kicked off by Voevodsky on the TYPES mailing list http://lists.seas.upenn.edu/pipermail/types-list/2014/001745.html

This article isn’t a piece of rigorous mathematics and I’m using mathematical terms as analogies.

The notion of a subproblem isn’t completely distinct from a quotient problem. Some problems are both, and in fact some problems can be solved by transforming them so they become both.

More generally, looking at computer programs through different filters is one approach to abstract interpretation http://en.wikipedia.org/wiki/Abstract_interpretation. The intuition section there (http://en.wikipedia.org/wiki/Abstract_interpretation#Intuition) has much in common with what I’m saying.

### Haskell for the Evil Genius

### Haskell for the Evil Genius

### Wanting to learn Haskell, then I hit this error before I can even start.

(Full error text available upon request. Error text trimmed due to max character limit.)

What I was doing (following the instructions in "Beginning Haskell"):

1. Installed XCode

2. Installed XCode command line tools

3. Installed Eclipse

4. Installed EclipseFP

5. Restarted Eclipse

6. Checked the boxes for "Install optional helper executables (...)" and "Install for current user only"

7. *Voila*, errors!

While I am a Haskell beginner, I do know my way around a few other programming languages. From this small body of knowledge I make the following observations:

* If you want your language to be taken as more than an academic language, don't have errors in commonly used code (the exceptions package has had this exact same error for at least two months now).

* There is a distinct lack of resources targeted at any level of expertise other than Haskell guru for working through problems such as the one above (a.k.a., I know this is the wrong place to post this but I am doing so anyhow out of desperation).

[link] [37 comments]

### System.Process and -threaded

### ICFP 2014 Student Research Competition: Call forSubmissions

### ICFP 2014 Student Research Competition: Call forSubmissions

### what did it take for you to get comfortable with Haskell ?

is it books you read, courses, meetings, projects you worked on...etc

submitted by pyThat[link] [28 comments]

### How do I learn Fay?

I've recently become interested in Haskell, and I'm working on my first project, a tic-tac-toe game. I have gotten the game to work on the command line, but I would also like to build a better interface with Fay/Javascript.

The problem is that I haven't found any good tutorials or explanations of Fay. Does anyone know any good resources for Fay, or should I just study the examples that are provided in the package?

submitted by Judde10[link] [4 comments]