News aggregator

ANN: HPi v0.5.0, controlling the GPIO pins of a Raspberry Pi from Haskell

Haskell on Reddit - Fri, 09/25/2015 - 9:34am

I'm pleased to announce that v0.5.0 of HPi is now available on Hackage (and github as well). Support for the RPi 2 and SPI communications have been added and tested and several bugs have been fixed. All those who want to use their favorite non-realtime super high level language for doing cutting edge low level stuff such as controlling LEDS now have even more options!

Comments, feature requests and bug reports are quite welcome.

submitted by WJWH
[link] [6 comments]
Categories: Incoming News

Mark Jason Dominus: A message to the aliens, part 14/23 (terrain)

Planet Haskell - Fri, 09/25/2015 - 8:06am

Earlier articles: Introduction Common features Page 1 (numerals) Page 2 (arithmetic) Page 3 (exponents) Page 4 (algebra) Page 5 (geometry) Page 6 (chemistry) Page 7 (mass) Page 8 (time and space) Page 9 (physical units) Page 10 (temperature) Page 11 (solar system) Page 12 (Earth-Moon system) Page 13 (days, months, and years)

This is page 14 of the Cosmic Call message. An explanation follows.

The 10 digits are:


This is my favorite page: there is a lot of varied information and the illustration is ingenious. The page heading says to match up with the corresponding labels on the previous three pages. The page depicts the overall terrain of the Earth. The main feature is a large illustration of some mountains (yellow in my highlighted illustration below) plunging into the sea (blue).

The land part is labeled , the air part , and the water part . Over on the left of the land part are little stick figures, labeled people . This is to show that people live on the land part of the Earth, not under water or in the air. The stick figures may not be clear to the recipients, but they are explained in more detail on the next page.

Each of the three main divisions is annotated with its general chemical composition, with compounds listed in order of prevalence., All the chemical element symblog were introduced earlier, on pages 6 and 7:

The lithosphere : silicon dioxide (SiO2) ; aluminium oxide (Al2O3) ; iron(III) oxide (Fe2O3) ; iron(II) oxide (FeO) . Wikipedia and other sources dispute this listing, giving instead: SiO2, MgO, FeO, Al2O3, CaO, Na2O, Fe2O3 in that order.

The atmosphere : nitrogen gas (N2) ; oxygen gas (O2) ; argon (Ar) ; carbon dioxide (CO2) .

The hydrosphere : water (H2O) ; sodium (Na) ; chlorine (Cl) .

There are rulers extending upward from the surface of the water to the height of top of the mountain and downward to the bottom of the ocean. The height ruler is labeled 8838 meters, which is the height the peak of Mount Everest, the point highest above sea level. The depth ruler is labeled 11000 meters, which is the depth of the Challenger Deep in the Mariana Trench, the deepest part of the ocean. The two rulers have the correct sizes relative to one another. The human figures at left are not to scale (they around about 1.7 miles high), but the next page will explain how big they really are.

I don't think the message contains anything to tell the recipients the temperature of the Earth, so it may not be clear that the hydrosphere is liquid water. But perhaps the wavy line here will suggest that. The practice of measuring the height of the mountains and depth of the ocean from the surface may also be suggestive of a liquid ocean, since it would not otherwise have a flat surface to provide a global standard.

There is a potential problem with this picture: how will the recipients know which edge is the top? What if they hold it upside-down, and think the human figures are pointing down into the earth, heads downwards?

This problem is solved in a clever way: the dots at the right of the page depict an object accelerating under the influence of gravity, falling in a characteristic parabolic path. To make the point clear, the dots are labeled with the glyph for acceleration.

Finally, the lower left of the page states the acceleration due to gravity at the Earth's surface, 9.7978 m/s2. The recipients can calculate this value from the mass and radius of the Earth given earlier. Linked with the other appearance of acceleration on the page, this should suggest that the dots depict an object falling under the influence of gravity toward the bottom of the page.

The next article will discuss page 15, shown at right. (Click to enlarge.) Try to figure it out before then.

Categories: Offsite Blogs

How to test your idea (predicates, key-functions) rather than the prelude function?

Haskell on Reddit - Fri, 09/25/2015 - 4:56am

Hi /r/haskell,

I absolutely love the idea of property-based testing, but I have a hard time coming up with good tests. A lot of the work I do is stringing maps, filters and sorts together. The thing is that I feel that I am not testing my ideas behind the composing of the functions, but rather the prelude functions themselves.

To give an example to guide the discussion, I had to write a program that given a blacklist of ids and a list of sets of ids has to remove the sets that contain one or more of the ids in the blacklist. (The original is written in python, but is reproduced here in Haskell. It's essentially the same).

import qualified Data.Set as Set blacklist = Set.fromList [2,3] idset = [Set.fromList[2,5,6], Set.fromList[5,4,6]] blacklist_filtering = filter (Set.null . Set.intersection blacklist) main = print $ blacklist_filtering idset {-- result := fromList[5,4,6] --}

So how would one test this? We could test that when we apply the blacklist filter again on the already filtered list that we should get the same result. However, does this really test my logic or is this more a test for filter? I think this is more a test for filter. One could argue that in a language like python which has side-effects/states that this is still useful. However I know that my function behaves as a function without side effects.

What would be a good test for blacklist_filtering, both in a functional language and in a non-functional language like python (which has property based testing support via the hypothesis package)? Or is this something you normally wouldn't test?

Furthermore, this question isn't limited to filter. You could do the same for sort, takewhile, etcetera, almost everything that takes a predicate or a key function. To expand, sort also acts idempotent, but you aren't really testing your 'key function' on which you would want to sort if you sort the same list again. (Assuming your using the prelude sort and not a custom one).

submitted by exarge
[link] [15 comments]
Categories: Incoming News

Call for Contributions: BOB 2016 - Berlin, Feb 19, 2016

Haskell on Reddit - Fri, 09/25/2015 - 3:49am
BOB Conference 2016 "What happens when we use what's best for a change?" Berlin, February 19 Call for Contributions Deadline: October 30, 2015

You drive advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer.

If you share our vision and want to contribute, submit a proposal for a talk or tutorial!


We are looking for talks about best-of-breed software technology, e.g.:

  • functional programming
  • reactive programming
  • persistent data structures and databases
  • types
  • formal methods for correctness and robustness
  • ... everything really that isn't mainstream, but you think should be.

Presenters should provide the audience with information that is practically useful for software developers. This could take the form of e.g.:

  • experience reports
  • introductory talks on technical background
  • demos and how-tos

We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German.

Your proposal should include (in your presentation language of choice):

  • an abstract of max. 1500 characters.
  • a short bio/cv
  • contact information (including at least email address)
  • a list of 3-5 concrete ideas of how your work can be applied in a developer's daily life
  • additional material (websites, blogs, slides, videos of past presentations, ...)

Submit here:


NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered.


The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides.

Program Committee

(more information here:

  • Matthias Fischmann, zerobuzz UG
  • Matthias Neubauer, SICK AG
  • Nicole Rauch, Softwareentwicklung und Entwicklungscoaching
  • Michael Sperber, Active Group
  • Stefan Wehr, factis research
Scientific Advisory Board
  • Annette Bieniusa, TU Kaiserslautern
  • Peter Thiemann, Uni Freiburg
submitted by 34798s7d98t6
[link] [comment]
Categories: Incoming News

ANN: CfN for new Haskell Prime language committee

General haskell list - Thu, 09/24/2015 - 10:56pm
Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at for more details. Cheers, hvr
Categories: Incoming News

Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

libraries list - Thu, 09/24/2015 - 10:43pm
Hello *, Concluding AMP and MFP, We (David and I) proudly present you the final installment of the Monad trilogy: Monad of no `return` Proposal ============================= TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Current Situation ----------------- With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy becomes class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b u *> v = … (<*) :: f a -> f b -> f a u <* v = … class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a return = pure (>>) :: m a -> m b -> m b m >> k = …
Categories: Offsite Discussion

ANNOUNCE: polymap

General haskell list - Thu, 09/24/2015 - 7:53pm
I'm excited to announce the first release of a package I've been working on over the last week called polymap, a library providing type-safe polygonal maps whose sides are defined by a kindlist of types zipped with a storage type for each side. I've tried to match the interface exposed by the containers package as closely as possible. For example: import Data.Set (Set) import Data.PolyMap.Nat (first, second, third) import qualified Data.PolyMap as PM mEmpty :: PM.PolyMap '[ '(String, Set), '(Int, Set) ] mEmpty = PM.empty mOne :: PM.SimplePolyMap '[String, Int] Set mOne = PM.singleton ("one", length "one") main = do print mEmpty -- empty PolyMap print mOne -- PolyMap with one Relation print mTwo -- PolyMapwith two Relations print (PM.member first "one" mTwo) -- True print (PM.notMember first "asdf" mTwo) -- True --print (PM.notMember second "asdf" mTwo) -- will not typeche
Categories: Incoming News

STM implementation

haskell-cafe - Thu, 09/24/2015 - 4:22pm
Hi all, I’m considering the idea of hacking into the STM implementation, but the source in rts/STM.c seems rather dense. Is there some documentation about the internals or some place to start to understand what’s going on? Thank you, Nicola _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Noam Lewis: Two implementations of DHM type inference

Planet Haskell - Thu, 09/24/2015 - 3:51pm

Here are two simple implementations of Damas-Hindley-Milner type inference.

First, is my Haskell version of a region-based optimized type checker as explained by Oleg Kiselyov, in his excellent review of the optimizations to generalization used in OCaml. Oleg gives an SML implementation, which I’ve Haskellized rather mechanically (using ST instead of mutable references, etc.) The result is a bit ugly, but it does include all the optimizations explained by Oleg above (both lambda-depth / region / level fast generalization and instantiation, plus path compression on linked variables, and not doing expensive occurs checks by delaying them to whenever we traverse the types anyway).

Second, here’s my much shorter and more elegant implementation using the neat unification-fd package by Wren Romano. It’s less optimized though – currently I’m not doing regions or other optimizations. I’m not entirely satisfied with how it looks: I’m guessing this isn’t how the author of unification-fd intended generalization to be implemented, but it works. Generalization does the expensive lookup of free metavariables in the type environment. Also the instantiate function is a bit clunky. The unification-fd package itself is doing inexpensive occurs checks as above, and path compression, but doesn’t provide an easy way to keep track of lambda-depth so I skipped that part. Perhaps the Variable class should include a parameterized payload per variable, which could be used for (among other things) keeping track of lambda-depth.

Tagged: Haskell
Categories: Offsite Blogs

The Incredible Proof Machine

Haskell on Reddit - Thu, 09/24/2015 - 9:40am
Categories: Incoming News

Darcs: darcs hacking sprint 9 report

Planet Haskell - Thu, 09/24/2015 - 9:35am
After a one year and a half absence, the Darcs Hacking Sprint returned!

Once again, the event occurred at the IRILL (Innovation and Research Initiative for Free Software) in Paris, on September 18th to 20th.

The sprint had 7 participants: Danill Frumin, Eric Kow, Florent Becker, Ganesh Sittampalam, Guillaume Hoffmann, Thomas Miedema and Vinh Dang.

Darcs and GHC 8Thomas Miedema is a Haskell and GHC hacker, and came on the first day of the sprint. Since Darcs is a system that aims at supporting the various GHC versions out there, Thomas helped us preparing for GHC 8, the next major version. He explained us one issue of GHC 8 that got triggered by Darcs: a bug with the PatternSynonyms extension. Fortunately it seems that the bug will be fixed in GHC HEAD. (First release candidate is planned for December).

Thomas explaining PatternSynonyms to Eric and GaneshDiving into SelectChanges and PatchChoices codeOn the first day I (Guillaume) claimed the "rollback takes ages" bug, which made me look into SelectChanges and PatchChoices code. The result is that I still haven't yet fixed the bug, but I discovered that patch matching was unnecessarily strict, which I could fix easily. Internally, there are two interesting patch types when it comes to matching:
  • NamedPatch: represent the contents of a patch file in _darcs/patches, that is, its info and its contents
  • PatchInfoAnd: represents the info of a patch as read from an inventory file (from _darcs/inventories or _darcs/hashed_inventory) and a lazy field to its corresponding NamedPatch.
Now, getting the NamedPatch for some patch is then obviously more costly than a PatchInfoAnd. You may even have to download the patch file in order to read it (in the case of lazy repositories). Moreover,  the majority of matchers only need the patch info (or metadata), not its actual contents. Only two matchers (hunk and touch) need to actually read the patch file, while matching or a patch name for instance (probably the most common operation) does not.

So, before the sprint, as soon as you wanted to match on a patch file, you had to open (and maybe download) its file, even if this was useless. With my change (mostly in Darcs.Patch.Match) we gained a little more laziness; and the unreasonably slow command "rollback -p ." passes from 2 minutes to ~15 seconds on my laptop. I hope to push this change into Darcs 2.10.2.

Eric, Guillaume and Vinh
Now, the real source of the "rollback -p ." slowness is that patch selection is done on FL's (Forward List), while commands like rollback and obliterate naturally work backwards in time on RL. Currently, an RL is inverted and then given to the patch selection code, which is not convenient at all! Moreover, the actual representation of history of a Darcs repository is (close to being) an RL. So it seems like a proper fix for the bug is to generalize the patch selection code to also work on RL's; which may involve a good amount of typeclass'ing in the relevant modules. I think this will be too big/risky to port to the 2.10 branch, so it will wait for Darcs 2.12.
Ganesh's new not-yet-officially-named stash command
A few days before the sprint, Ganesh unveiled his "stash" branch. It feature a refactoring that enables to suspend patches (ie, put them into a state such that they have no effect in the working copy) but without changing their identity (which is currently what occurs with the darcs rebase command). This enables to implement a git-stash-like feature.
The sprinters (IRL and on IRC) discussed the possible name of the command that should encapsulate this stash feature. More importantly, on the last day we discussed what would be the actual UI of such a feature. As always when a new feature is coming to darcs, we want to make the UI as darcsy as possible :-)
Coming back to the code, Ganesh's refactoring, if extensive, will also simplify the existing types for suspended patches. We decided to go with it.Dan's den
Dan demonstrating den (on the left: Florent)Daniil Frumin was this years Google Summer of Code student for Darcs. Mentored by Ganesh, he brought improvements to Darcsden, many of them being already deployed. Among them, it is possible to launch a local instance of Darcsden (using an executable called den), not unlike Mercurial's "serve" command.
Dan tells more about his work and this sprint in his latest blog post.
A better website and documentationAs a newcomer to the project, Vinh took a look at the documentation, especially the website of the project. He implemented changes to make the front page less intimidating and more organized. He also had a fresh look at our "quickstart" and proposed improvements which we felt were much needed!
Florent's projectsFor this sprint, Florent was more an external visitor than a Darcs hacker. He talked about one of his current projects: Pijul, a version control system with another approach. Check out their website!
Conclusion and the next sprintIn the end this sprint turned out to be more productive and crowded than we initially thought! It has been a lot of time since the previous one, so we had a lot of things to share at first. Sprints do make synchronization between contributors more effective. They are also a moment when we can get more concentrated on the Darcs codebase, and spend more time tacking some issue.

Avenue d'Italie, ParisWe would like to thank the IRILL people for hosting the sprint for the third time and our generous donators to make travelling to sprints easier.

We already have a time and a place for the next sprint: Sevilla, Spain in January 2016! The exact moment will be announced later, but you can already start organizing yourself and tell us if you're going.

Thomas, Eric and GaneshFrom left to right: Vinh, Florent, Dan, Ganesh and Eric
Categories: Offsite Blogs