News aggregator

Going insane over overlapping instances

haskell-cafe - Sun, 05/22/2016 - 6:05pm
This is driving me nuts. So I have a type class HasStructParser I've defined. Details are irrelevant except that if you have HasStructParser defined, then ToJSON is also defined. So I have: instance HasStructParser s => ToJSON s where ... But now, any type that defines ToJSON any other way causes an Overlapping Instances error to happen- the conflict being between the real ToJSON implementation and the one deriving from HasStructParser- this despite the fact that there is no implementation for HasStructParser for the given type. Now, I don't want to allow Overlapping Instances because if there are *real* overlapping instances, I want that to be an error. For instance, if a structure did implement HasStructParser and some other implementation of ToJSON, I want to know. I suppose I could go: newtype JSON a = JSON a instance HasStructParser s => ToJSON (JSON s) where ... But this strikes me as being ugly- now I have to add pointless JSON constructors everywhere I want to convert to
Categories: Offsite Discussion

Stefan Jacholke: Project Proposal

Planet Haskell - Sun, 05/22/2016 - 6:00pm
Visual functional block-based programming language for CodeWorld Introduction

The goal of this project is to develop a functional-based visual blocks-based programming language, similar to Scratch and other languages, that is based on a subset of Haskell. The project will extend CodeWorld and will use its API. The project will feature a user interface to allow the user to snap, drag and drop blocks in order to construct CodeWorld programs.

The language will be a prototype as a full language is beyond the current scope and timeframe. Future work and stretch goals are presented as well.

The project is an extension to CodeWorld, which is an educational web-based programming environment A visual language is a great way to get students started with programming and a functional language might be well suited to such composition.

Outline User interface

Development of a friendly user interface.

  • A user-friendly interface will be designed and implemented
  • Bootstrap or a similar HTML/CSS framework will be used to design the interface. The user interface logic will be implemented using Javascript and Jquery.
  • The user interface of the project will utilize Blockly.
  • Blockly will be adapted to match the functional style and various blocks will be created in order to match the CodeWorld API.

Haskell code generation

  • Blockly applications turn blocks into code in order to execute.
  • The project will generate valid Haskell CodeWorld programs from the blocks.
  • The code generation will be done using GHCJS with an intermediate block language layer handling the visual language before generating valid CodeWorld code.
  • Each shape represents a type. A block (that consists of a shape) will have multiple slots or parameters into which other blocks can be inserted.
  • Allow creation of top-level definition blocks / functions than can be reused. A separate tab/panel for construction of definitions will be available in the interface
Validation and Error messages

Validation and verification of a valid program.

  • Ensure only valid programs can be constructed. Blocks should only be able to be connected if their types match.
  • If snapping does not occur, visually tell the user why (tell them what type was expected, if possible)
  • If an error does occur it should be displayed in a friendly manner.
  • When hovering over a slot it should display what input type is expected.
  • Blocks should indicate their output type.
Polymorphic types

Some blocks will have to handle polymorphic types.

  • Blocks may have multiple slots; if a slot gets connected the other slots might change color if the are the same type. For example, if we have an IF (condition) (consequence) (alternative) block then when either consequence or alternative is connected the other slot should reflect the same type.
  • Blocks might also change color to reflect their type.
  • Minimal handling of polymorphic types will be included in order to accommodate CodeWorld’s API. Complete integration is seen as a stretch goal (if time allows).
  • User data can be constructed from a set of basic types. Constructors and destructors will allow manipulations of the data.
CodeWorld integration
  • Blocks to reflect CodeWorld functions and data types, such that CodeWorld programs can be built.
  • Most CodeWorld functions are monomorphic, however, simulations require a polymorphic state/world type. We propose that such data types be constructed from existing primitive types using constructors and destructors.
What might need to be excluded
  • Custom algebraic data types. Since blocks are predefined there may not be a way to extract data from a user-defined data type.

Weekly communication will be made with the mentor to ensure the project is on track.

Before June 12 - Research into current visual block-based programming languages such as Scratch, what good ideas they utilize and what can be carried over to this project. Research into some of the current problems that a functional based visual programming language faces.

June 12th - Deliverable - Mock up design of the user interface. Overview of what blocks might be supported.

June 13th - June 30th - Design of the functional block based language. Set up of CodeWorld and Blockly

July 1st - July 30th - Setup of a basic interface, incorporate Blockly and interface with CodeWorld. Discover and overcome unsuspected challenges

July 31st - Deliverable - Basic user interface set up. A basic program should be able to built using the user interface.

August 1st - August 15th - Implement Codeworld functions and types. Complete Blockly code generation.

August 16th - Deliverable - CodeWorld example programs should be able to be built.

August 16th - September 2nd - Polish user interface, improve error messages, fix bugs. Some leeway for the unexpected.

I have limited availability from 4 - 7 September due to a conference. It does not seem to interfere with any important dates.

I will communicate with my mentor if there are any other difficulties.

Stretch Goals

If time allows and a good solution presents itself the following may be implemented (but is not part of the core project), otherwise they are presented as good ideas for future versions:

  • Pattern Matching
  • Support for ADT’s
  • Support for editing list comprehensions, live previews of list comprehensions
  • Full recursion support
  • First class functions
About me     Name Stefan Jacholke University NWU Potchefstroom Course M.Eng Computer Degree B.Eng Computer and Electronic Email Github

I’m a first-year computer engineering graduate student at NWU in South Africa, studying Network Optimization and Planning.

My current interests include Programming Languages, Algorithms, and Data structures.

While I have only recently started developing in Haskell I have used it for:

  • Developing my own simple programming language
  • Developed a simple math expression simplifier
  • Am currently developing a mobile coffee purchases mobile application; the backend for the application is written in Haskell (that handles credit card purchases, queries to the POS system, interface between app and database)
  • Using Haskell for algorithmic problems (HackerRank, Codejam)
  • Used FFI binding to interface with CPLEX (commercial linear programming solver)
  • Using it to develop my framework for Metro Ethernet optimization (Master’s project)

I have experience in Web development, mostly through some of my pregraduate courses. In particular, I have:

  • Developed a Real Estate web site for advertisements using ASP.NET, MySQL, and ReactJS
  • Developed a File management site for uploading and downloading files (similar to dropbox, though simpler) using PHP, Bootstrap and Jquery and AJAX

Various experience with other technologies (though unrelated to project at hand). I also have a few other projects in different languages.

I have some small open source contributions listed on my Github profile.

More information can be given on request.


This project is based on Chris Smith’s proposal for a block-based UI for CodeWorld

Categories: Offsite Blogs

Dan Burton: Stackage LTS and GHC 8.0

Planet Haskell - Sun, 05/22/2016 - 5:19pm
The release of GHC 8.0.1 has recently been announced. Hooray! People are already asking about when LTS Haskell will include the new GHC. While I’m also excited for this to happen as soon as possible, it’s worth taking a look … Continue reading →
Categories: Offsite Blogs

ANNOUNCE: testbench-

haskell-cafe - Sun, 05/22/2016 - 3:23pm
I've just released a new library onto Hackage that aims to help you writing comparison-oriented benchmarks by: a) reducing the duplication found when using criterion directly b) let you test your benchmarked values/functions to ensure that they have the same result/satisfy a given predicate c) provide more comparison-oriented output I've written more about it here: Or you could go straight to the Hackage page here:
Categories: Offsite Discussion

Ivan Lazar Miljenovic: Test your benchmarks!

Planet Haskell - Sun, 05/22/2016 - 8:21am

There are lies, damn lies and benchmarks.
Old Jungle saying

testbench is a new library designed to make it easier to write comparison benchmarks, ensure that they return the correct value and thus help prevent unintentional bias in benchmarks.


About a year ago, I was working on some Haskell code that I wanted to compare to existing implementations. In Haskell, we of course have the wonderful criterion library to write benchmarks with, but whilst I’ve found it really helpful before to help me tell whether a particular function has been improving in performance as I work on it, I felt that it was a bit clunky for directly comparing implementations against each other (there used to be a [bcompare] function, but it hasn’t existed since version which came out in August 2014).

When I tried looking at how others have approached this problem, I found that they did so by just directly using the bench and bgroup functions. From my point of view, there are two problems with this approach:

  1. There is a lot of duplication required with this: you would typically have something along the lines of: [ bench "f1" $ nf f1 a , bench "f2" $ nf f2 a ... ]

    Because of this duplication, it is too easy to have benchmarks nominally comparing two (or more) functions/values, but accidentally end up comparing apples to oranges (e.g. using whnf instead of nf).

  2. The output generated by criterion – especially as of version – is rather verbose and tends not to lend itself well to directly comparing results to multiple benchmarks. I personally find myself starting to get swamped looking at the terminal output if there’s more than a few benchmarks, and the HTML report is even worse.As I said above, it’s great when I’m directly looking at just how one function compares as I tweak it, but not when I’m wanting to compare multiple functions.

Whilst I kept looking at existing comparison benchmarks, I even came across an example where a comparison ended up nominally showing that f1 was faster than f2… except that the result of f1 was a value with an O(1) implementation of [rnf], whereas f2 has an O(n) definition. I don’t know if this is intentional (I think it probably wasn’t) and even if this is rectified f1 was still faster… but the difference in runtimes – whilst minor in comparison to performance between the two functions – is non-negligible.

This to me demonstrated the desirability of not only having a wrapper around criterion to reduce the verbosity of comparison benchmarks, but to only be able to produce unit tests to ensure criteria are satisfied.

It’s taken me longer than I wished to produce a syntax that I was both happy with and would actually work (with lots of fighting against GHC in the form of “Why won’t you accept this? Oh, wait, now I get it; that makes sense… but can’t you accept it anyway? Pretty please?”), but I’ve now finally gotten it to a usable form and am hence releasing it.

testbench is now available on Hackage with the source on GitHub.


As extremely simple and contrived examples, consider the following:

main :: IO () main = testBench $ do -- Monomorphic comparisons compareFunc "List length" (\n -> length (replicate n ()) == n) (testWith (@? "Not as long as specified") <> benchNormalForm) (mapM_ (\n -> comp ("len == " ++ show n) n) [1..5]) -- Polymorphic comparisons. -- -- Currently it isn't possible to use a Proxy as the argument to the -- function, so we're using 'undefined' to specify the type. compareFuncConstraint (Proxy :: Proxy (CUnion Eq Num)) "Number type equality" (join (==) . (0`asTypeOf`)) (baseline "Integer" (undefined :: Integer) <> benchNormalForm) $ do comp "Int" (undefined :: Int) comp "Rational" (undefined :: Rational) comp "Float" (undefined :: Float) comp "Double" (undefined :: Double)

When this is run, the result on the console is:

Cases: 9 Tried: 9 Errors: 0 Failures: 0 Mean MeanLB MeanUB Stddev StddevLB StddevUB OutlierVariance List length len == 1 22.15 ns 21.86 ns 22.88 ns 1.505 ns 742.2 ps 2.826 ns 83% len == 2 22.64 ns 22.49 ns 22.87 ns 602.0 ps 449.5 ps 825.7 ps 43% len == 3 23.39 ns 23.16 ns 23.78 ns 1.057 ns 632.6 ps 1.553 ns 68% len == 4 23.70 ns 23.51 ns 23.95 ns 773.3 ps 567.9 ps 1.050 ns 53% len == 5 24.14 ns 23.96 ns 24.71 ns 962.4 ps 307.5 ps 1.886 ns 63% Number type equality Integer 12.59 ns 12.48 ns 12.80 ns 538.0 ps 312.4 ps 944.2 ps 67% Int 12.79 ns 12.69 ns 12.98 ns 463.6 ps 320.0 ps 665.2 ps 59% Rational 12.77 ns 12.67 ns 12.93 ns 395.1 ps 290.0 ps 535.9 ps 51% Float 13.13 ns 12.88 ns 13.42 ns 869.7 ps 667.3 ps 1.212 ns 83% Double 12.74 ns 12.57 ns 13.02 ns 704.6 ps 456.5 ps 1.047 ns 78%

You can see on the top line we’ve had nine tests (run using HUnit):

  • From the first group we’ve specified that all five values must return True.
  • From the second group, we’ve specified that all inputs must return the same value as for the Integer case.

Since all the tests passed, the benchmarks are run. The output for these is a tabular format to make it easier to do vertical comparisons (though in this case the variances are all high so we should take them with a grain of salt).


Whilst I’m quite pleased with the API for defining the actual tests/benchmarks (subject to what GHC will let me write), there’s still scope for more functionality (e.g. support for IO-based benchmarks).

However, the default output (as soon above) isn’t configurable. It’s possible to get the individual tests and benchmarks out to feed them explicitly to HUnit and criterion respectively, but if you’re after this particular output then you have to wait until all the benchmarks are complete before the results are printed. There is no support for saving results to file (either as a CSV of all the results or an HTML report), or even to control how the benchmarks are run (minimum time spent on each benchmark, etc.) or any other option currently offered by criterion.

If there is enough interest I can look at adding these in; but this satisfies my itch for now whilst getting this library out there for people to start trying out.

Filed under: Haskell
Categories: Offsite Blogs

Interacting with Java in GHCVM

haskell-cafe - Sun, 05/22/2016 - 3:54am
Hi Haskell-Cafe, I've been working on a JVM backend for GHC [1] and I took some time to flesh out a design for the Java FFI [2] which will pretty much decide whether the project will be useful or not. I would love feedback from the community on how to improve the design or requests for important interop features that I have neglected. Thanks, Rahul Muttineni [1] [2] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Gabriel Gonzalez: A command-line benchmark tool

Planet Haskell - Sat, 05/21/2016 - 8:32am

I wrote a small program named bench that lets you benchmark other programs from the command line. Think of this as a much nicer alternative to the time command.

The best way to illustrate how this works is to show a few example uses of the program:

$ bench 'ls /usr/bin | wc -l' # You can benchmark shell pipelines
benchmarking ls /usr/bin | wc -l
time 6.756 ms (6.409 ms .. 7.059 ms)
0.988 R² (0.980 R² .. 0.995 R²)
mean 7.590 ms (7.173 ms .. 8.526 ms)
std dev 1.685 ms (859.0 μs .. 2.582 ms)
variance introduced by outliers: 88% (severely inflated)

$ bench 'sleep 1' # You have to quote multiple tokens
benchmarking sleep 1
time 1.003 s (1.003 s .. 1.003 s)
1.000 R² (1.000 R² .. 1.000 R²)
mean 1.003 s (1.003 s .. 1.003 s)
std dev 65.86 μs (0.0 s .. 68.91 μs)
variance introduced by outliers: 19% (moderately inflated)

$ bench true # The benchmark overhead is below 1 ms
benchmarking true
time 383.9 μs (368.6 μs .. 403.4 μs)
0.982 R² (0.971 R² .. 0.991 R²)
mean 401.1 μs (386.9 μs .. 418.9 μs)
std dev 54.39 μs (41.70 μs .. 67.62 μs)
variance introduced by outliers: 87% (severely inflated)

This utility just provides a command-line API for Haskell's criterion benchmarking library. The bench tool wraps any shell command you provide in a a subprocess and benchmarks that subprocess through repeated runs using criterion. The number of runs varies between 10 to 10000 times depending on how expensive the command is.

This tool also threads through the same command-line options that criterion accepts for benchmark suites. You can see the full set of options using the --help flag:

$ bench --help
Command-line tool to benchmark other programs

Usage: bench COMMAND ([-I|--ci CI] [-G|--no-gc] [-L|--time-limit SECS]
[--resamples COUNT] [--regress RESP:PRED..] [--raw FILE]
[-o|--output FILE] [--csv FILE] [--junit FILE]
[-v|--verbosity LEVEL] [-t|--template FILE] [-m|--match MATCH]
[NAME...] | [-n|--iters ITERS] [-m|--match MATCH] [NAME...] |
[-l|--list] | [--version])

Available options:
-h,--help Show this help text
COMMAND The command line to benchmark
-I,--ci CI Confidence interval
-G,--no-gc Do not collect garbage between iterations
-L,--time-limit SECS Time limit to run a benchmark
--resamples COUNT Number of bootstrap resamples to perform
--regress RESP:PRED.. Regressions to perform
--raw FILE File to write raw data to
-o,--output FILE File to write report to
--csv FILE File to write CSV summary to
--junit FILE File to write JUnit summary to
-v,--verbosity LEVEL Verbosity level
-t,--template FILE Template to use for report
-m,--match MATCH How to match benchmark names ("prefix" or "glob")
-n,--iters ITERS Run benchmarks, don't analyse
-m,--match MATCH How to match benchmark names ("prefix" or "glob")
-l,--list List benchmarks
--version Show version info

The --output option is really useful: it outputs an HTML page with a chart showing the distribution of run times. For example, the following command:

$ bench 'ls /usr/bin | wc -l' --output example.html
benchmarking ls /usr/bin | wc -l
time 6.716 ms (6.645 ms .. 6.807 ms)
0.999 R² (0.999 R² .. 0.999 R²)
mean 7.005 ms (6.897 ms .. 7.251 ms)
std dev 462.0 μs (199.3 μs .. 809.2 μs)
variance introduced by outliers: 37% (moderately inflated)

Also produces something like the following chart which you can view in example.html:

You can also increase the time limit using the --time-limit option, which will in turn increase the number of runs for better statistics. For example, criterion warned me that I had too many outliers for my benchmarks, so I can increase the time limit for the above benchmark to 30 seconds:

$ bench 'ls /usr/bin | wc -l' --time-limit 30 --output example.html
benchmarking ls /usr/bin | wc -l
time 6.937 ms (6.898 ms .. 7.002 ms)
1.000 R² (0.999 R² .. 1.000 R²)
mean 6.905 ms (6.878 ms .. 6.935 ms)
std dev 114.9 μs (86.59 μs .. 156.1 μs)

... which dials up the number of runs to the ~4000 range, reduces the number of outliers, and brings down the standard deviation by a factor of four:

Keep in mind that there are a few limitations to this tool:

  • this tool cannot accurately benchmark code that requires a warm up phase (such as JVM programs that depend on JIT compilation for performance)
  • this tool cannot measure performance below about half a millisecond due to the overhead of launching a subprocess and bash interpreter

Despite those limitations, I find that this tool comes in handy in a few scenarios:

  • Preliminary benchmarking in the prototyping phase of program development
  • Benchmarking program pipelines written in multiple languages

You can install this tool by following the instructions on the Github repo:

Or if you have the Haskell stack tool installed you can just run:

$ stack update
$ stack install bench
Categories: Offsite Blogs

Haskell Meetup group in Delhi, India

haskell-cafe - Sat, 05/21/2016 - 7:44am
Hi all, I just started a meetup group for Haskellers in and around Delhi NCR, India. The plan is to organise regular (monthly) meetups, talks, workshops etc for Haskell / FP enthusiasts at all skill levels. Anyone interested is welcome to join at - Also, since we are just getting started, the best way to help right now would be to spread the word! Thanks, Anupam Jain
Categories: Offsite Discussion

The GHC Team: GHC 8.0.1 is available!

Planet Haskell - Sat, 05/21/2016 - 7:24am

The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including,

  • A more refined interface for implicit call-stacks, allowing libraries to provide more helpful runtime error messages to users
  • The introduction of the DuplicateRecordFields language extension, allowing multiple datatypes to declare fields of the same name
  • Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports
  • A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches
  • More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools
  • Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators
  • The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings
  • Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets
  • A greatly improved user's guide, with beautiful and modern PDF and HTML output
  • Introduction of type application syntax, reducing the need for proxies
  • More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor
  • Support for injective type families and recursive superclass relationships
  • An improved generics representation leveraging GHC's support for type-level literals
  • The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level
  • ...and more!

A more thorough list of the changes included in this release can be found in the ​release notes,

As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, Please let us know if you encounter anything missing or unclear on this page.

This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve.

How to get it

Both the source tarball and binary distributions for a wide variety of platforms are available here.


Haskell is a standardized lazy functional programming language.

The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license.

Supported Platforms

The list of platforms we support, and the people responsible for them, can be found on the GHC wiki

Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform.


We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's ​developer site.

Community Resources

There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface.

There are several other Haskell and GHC-related mailing lists on ​; for the full list, see the ​lists page.

Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details.

Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here.

Categories: Offsite Blogs

Proposal: add fromRight and fromLeft to Data.Either

libraries list - Fri, 05/20/2016 - 9:08pm
When working with Either, I am often missing two simple functions: fromRight :: Either a b -> b fromLeft :: Either a b -> a It has been implemented a couple of times: But I don't want to depend on yet another library for such a basic function. Could it be added? Anton
Categories: Offsite Discussion

Modeling space for a MUD - revisited.

haskell-cafe - Fri, 05/20/2016 - 5:47pm
This is a continuation of a conversation started in the following two links.!searchin/haskell-cafe/michael$20litchard|sort:date/haskell-cafe/n0Tc29UUgoQ/iitt3z3PCwAJ!searchin/haskell-cafe/michael$20litchard|sort:date/haskell-cafe/qD2kaZ9qpEA/jTDAp8KoCgAJ I am trying to model a 3-D space for a mudlike. Here's the criteria I have so far: (1) Objects in space will be either ships that can move or stationary things like non-moving game-controlled ships, space-stations , moons and planets. (2) Objects will not have spatial extent (3) Space is non-continuous (4) Collision happens only when one object is stationary or each moving objects are moving directly toward each other, on the same line. (5) Movement happens by setting a destination vector and a speed. There's no steering exactly, but you can change destination while moving, slow down or stop suddenly. (6) Octree looks like the data structure I want to use for modeling. I'm looking a
Categories: Offsite Discussion

Neil Mitchell: Another space leak: QuickCheck edition

Planet Haskell - Fri, 05/20/2016 - 8:29am

Summary: QuickCheck had a space leak in property, now fixed (in HEAD).

Using the techniques described in my previous blog post I found another space leak, this time in QuickCheck, which has now been fixed. Using QuickCheck we can chose to "label" certain inputs, for example:

$ quickCheck $ \p -> label (if p > 0 then "+ve" else "-ve") True
+++ OK, passed 100 tests:
54% -ve
46% +ve

Here we label numbers based on their value, and at the end QuickCheck tells us how many were in each set. As you might expect, the underlying QuickCheck implementation contains a Map String Int to record how many tests get each label.

Unfortunately, the implementation in QuickCheck-2.8.1 has a space leak, meaning that the memory usage is proportional to the number of tests run. We can provoke such a space leak with:

quickCheckWithResult stdArgs{maxSuccess=10000} $
\(p :: Double) -> label "foo" True

When running with ghc --make Main.hs -rtsopts && Main +RTS -K1K we get the error:

Main: Stack space overflow: current size 33624 bytes.

Using -K1K we have detected when we evaluate the space leak, at the end of the program, when trying to print out the summary statistics. The approach taken by QuickCheck for label is to generate a separate Map String Int per run, then at each step merge these Map values together using unionWith (+). As such, there are two likely culprits for the space leak:

  • Perhaps the Map is not evaluated, so in memory we have unionWith (+) x1 $ unionWith (+) x2 $ unionWith (+) x3 $ ....
  • Perhaps the values inside the Map are not evaluated, so in memory we have Map {"foo" = 1 + 1 + 1 + ...}.

QuickCheck avoids the first space leak by keeping its intermediate state in a record type with a strict field for the Map. QuickCheck suffers from the second problem. As usual, actually fixing the space leak is easy - just switch from importing Data.Map to Data.Map.Strict. The Strict module ensures that the computations passed to unionWith are forced before it returns, and the memory usage remains constant, not linear in the number of tests.

I detected this space leak because the Shake test suite runs with -K1K and when running one particular test on a Mac with GHC 8.0 in profiling mode it caused a stack overflow. I did not diagnose which of those factors was the ultimate cause (it may have even been the random seed at a particular point in time - only certain inputs call label).

Many space leaks are now easy to detect (using -K1K), moderate difficulty to debug (using the -xc technique or just by eye) and usually easy to fix.

Categories: Offsite Blogs

Philip Wadler: Cycling Fallacies

Planet Haskell - Fri, 05/20/2016 - 4:05am
Cycling Fallacies is a handy reference from The Cycling Embassy of Great Britain. A sample entry is copied below. Spotted by Ewen Maclean.

Your cycling fallacy is…<section class="fallacy_claim"> “If you put in a cycle lane, or pedestrianise a road, shops will get less business.”
</section> <section class="fallacy_response"> The ResponseCycling infrastructure (or pedestrianisation) does not restrict access to shops – it can actually make the streets and roads shops are on nicer places to visit, increasing footfall, and overall demand.
Many studies – from the Netherlands in the 1970s, to big US cities in the 2010s – have found that installing cycle infrastructure does not have a negative effect on income of businesses, and in most cases has a positive effect.
It's a popular myth that people who arrive by car spend more. People who arrive at shops on foot, or by bike, may spend less per visit, but they will visit more often, and they will spend more money overall. And being able to access a shop easily by foot or by cycle means that more frequent trips involving smaller ‘baskets’ become more convenient.
The headline message is: well-designed streets that make cycling and walking attractive are good for business. And in any case, cycling infrastructure won't stop people driving to shops, or parking near them and walking a short distance.

Further reading<section id="links_in_main_language"> </section></section>
Categories: Offsite Blogs

ANNOUNCE: accelerate-typelits

haskell-cafe - Thu, 05/19/2016 - 11:16pm
I want to announce my first haskell project big/clean enough so I consider it possibly useful to others - accelerate-typelits is a library that provides vectors/matrices in a typesafe way - i.e. The dimension of the entities are stored on type level as (Nats). There is basic vector/matrix functionality, documentation and tests for those functions (mostly properties). If I have time I will provide some basic examples and a bit more complicated example within the next week. It is available on hackage as well as on github I would be happy to get some feedback. - Martin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

DSLDI 2016: Call for Talk Proposals

General haskell list - Thu, 05/19/2016 - 10:24pm
********************************************************************* CALL FOR TALK PROPOSALS DSLDI 2016 Fourth Workshop on Domain-Specific Language Design and Implementation October 31, 2016 Amsterdam, Netherlands Co-located with SPLASH ********************************************************************* Deadline for talk proposals: August 1, 2016 *** Workshop Goal *** Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. The goal of the DSLDI workshop is to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the w
Categories: Incoming News

ANNOUNCE: Sifflet 2.3.0 - recursion learning aid / visual programming language

haskell-cafe - Thu, 05/19/2016 - 7:12pm
Sifflet 2.3.0 is now available on Hackage. This release brings Sifflet up to date, so it compiles with GHC 7.10.3, newer versions of depended-on libraries, and builds in a cabal sandbox. Sifflet is the visual, functional programming language and support system for students learning about recursion. Sifflet programmers define functions by drawing diagrams, and the Sifflet interpreter uses the diagrams to show how function calls are evaluated. The Sifflet library (formerly sifflet-lib package) is reintegrated into, and deprecated in favor of, the sifflet package. A test suite is added. Personal Note ------------- It's been about 18 months since I've been able to work on this project or do any serious Haskell development. A lot has changed in the Haskell world -- a lot of catching up to do! It feels good getting back to Haskell again. About Sifflet ------------- Sifflet is a visual, functional programming language intended as an aid for learning about recursion. * A picture explains Sifflet better
Categories: Offsite Discussion

CFP (Approaching Deadline): IEEE DS-RT 2016 - SpecialSession tracks

General haskell list - Thu, 05/19/2016 - 3:37pm
Dear Colleagues and Researchers, Apologies, if you have received multiple copies of this CFP. ********** CALL FOR PAPER ********** 20th IEEE/ACM* International Symposium on Distributed Simulation and Real Time Applications September 21 - 23, 2016, London, UK *IEEE/ACM Pending Upon Approval DS-RT 2016 is running four special sessions this year: - Simulation of Urban Traffic Management and ITS - Distributed Simulations of Distributed Systems - Augmented and Virtual Reality for Real-Time Applications - Agent-based Modeling and Simulation Those special sessions cover prominent areas of the field of distributed simulations and real time applications, and many papers were accepted in previous editions of DS-RT on the same topics. See below for more detailed descriptions of those special sessions. Authors of selected papers will be invited to submit extended versions of their papers to a special issue on "Data-driven and Large-scale Distributed Simulation"
Categories: Incoming News

Proposal: add full complement of support for decreasing things in Data.Map

libraries list - Thu, 05/19/2016 - 3:00pm
Data.Map offers functions to convert from ascending lists to maps, and also offers a function to map an increasing function over the keys of a map. Equivalents for descending lists and decreasing functions are missing. I think we should add them. Any objections? _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

[ANN] Final Call for Papers: Erlang Workshop 2016 -- Submission deadline (3 June) approaching

General haskell list - Thu, 05/19/2016 - 12:28pm
Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Fifteenth ACM SIGPLAN Erlang Workshop ------------------------------ ----------------------------- Nara, Japan, September 23, 2016 Satellite event of the 21st ACM SIGPLAN International Conference on Functional Programming (ICFP 2016) September 18-24, 2016 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas
Categories: Incoming News

RV 2016, Deadline for abstract on May 20 (AoE)

General haskell list - Thu, 05/19/2016 - 10:41am
Following several requests, the deadlines have been extended as follows: - Abstract deadline: Friday May 20 (AoE). - Paper and tutorial deadline: Friday May 27 (AoE). =============================================== RV 2016 16th International Conference on Runtime Verification September 23-30, Madrid, Spain <> Scope Runtime verification is concerned with monitoring and analysis of software and hardware system executions. Runtime verification techniques are crucial for system correctness, reliability, and robustness; they are significantly more powerful and versatile than conventional testing, and more practical than exhaustive formal verification. Runtime verification can be used prior to deployment, for testing, verification, and debugging purposes, and after deployment for ensuring reliability, safety, and security and for providing fault containment and recovery as well as online system repair. Topics of interest to the conference include: - specification
Categories: Incoming News