News aggregator

language-puppet: Language-puppet 0.14.0

Planet Haskell - Fri, 06/13/2014 - 5:59am

A new version is out, and the version bump is here because it might now break catalog builds (despite no API change). The resource relationship resolver has been completely reworked, and should now work a bit more like Puppet does. It should now properly flag unknown resources used in relationships, or relationship loops.

There is another feature that might be of interest to those who don’t feel like editing modules that are contributed by other persons. An important class of modules are those that are officially supported by puppetlabs. language-puppet should strive to support all of them, but most of them demonstrate bad practices that are frowned upon by Puppetlabs itself (such as the reliance on the inheritance parameters pattern instead of Hiera), and some of them rely on features I specifically want to avoid (such as failed lookups returning undef).

You can now use the --ignoremodules options to prevent puppetresources from interpreting those modules, letting you test the other parts of your manifests. This will however fail if you reference a resource from these modules from your code …

Complete changelog
  • New features
    • Overhauled the dependency check system
    • Added an option to skip the user and group checks
    • Added an option to ignore some modules
  • Bugs fixed
    • Added vagrant, nagios, www-data, postgres and nginx to the list of known users.
    • Fixed how resource relationships were resolved with notify and before.
    • Fixed a problem where inheritance whould be used with :: prefix.
    • The defined function now works with classes.
    • All numbers are now strings in templates.
Categories: Offsite Blogs

HART 2014 - Second Workshop on Haskell And Rewriting Techniques (co-located with ICFP 2014)

General haskell list - Fri, 06/13/2014 - 5:21am
2nd CALL FOR PAPERS Second Workshop on Haskell And Rewriting Techniques (HART 2014) To be held on September 5, co-located with ICFP, the Haskell Symposium, etc., in Gothenburg. Haskell is an advanced purely-functional programming language. Pure functional programming is programming with equations, often defined by pattern-matching. Rewriting is the science of replacing equals by equals and thus a very powerful method for dealing with equations, often constructor-based. There are strong connections between Haskell (or generally, pure functional) programming and rewriting. The purpose of the HART workshop is to foster those connections. In addition to an invited talk by Oleg Kiselyov, we plan a half day of discussions, in an informal setting, on how Haskell (and related languages) and rewriting techniques and theories can cross-fertilize each other. Topics of interest are, for example: ============================
Categories: Incoming News

[Discussion] What would be the advantages/disadvantages of learning haskell as a first language?

Haskell on Reddit - Fri, 06/13/2014 - 12:53am

Besides the obvious headaches that come with learning programming in general, opinions?

Edit: I am not asking for myself, I just thought "what if?"

[link] [31 comments]
Categories: Incoming News

mightybyte: A Hopefully Fair and Useful Comparison of Haskell Web Frameworks

Planet Haskell - Thu, 06/12/2014 - 11:24pm
Recently there has been a lot of discussion and questions about the differences between the big three Haskell web frameworks: Happstack, Yesod, and Snap. Different pieces of the answer have been discussed in a number of places. In this post, I'd like to try to give a more complete comparison. Hopefully it will be relatively unbiased, but without being so watered down that it is useless. I've succeeded if you can't tell which framework I'm a major contributor to based solely on the text of this post.
Happstack First, up is Happstack, the oldest of the three with original commit history as early as February, 2005. Happstack used to be called HAppS. It was primarily composed of a web server based on lazy IO, a fairly radical (for the time) in-memory persistence approach for storing and versioning native Haskell data types, and a library called IxSet for making it easier to use this state system with relational data access patterns. I've heard a number of people describe HAppS (and Happstack) as being synonymous with this unconventional state system, but today the state system has been completely rewritten and rebranded as a standalone persistence system called acid-state.

Of the three frameworks, Happstack is probably the least monolithic and exists mostly as a loose collection of libraries that can be mixed and matched to suit one's needs. A quick search for "happstack" on hackage will reveal a large number of libraries providing a diverse range of functionality. This includes support for at least four template systems: Hamlet, Heist, HSP, and StringTemplate. The main Happstack maintainer also maintains a type-safe URL called web-routes which, if carefully used, provides compile-time guarantees that your site won't have broken internal links.

While Happstack includes support for the widest range of choices, its most visible members do seem to favor a few in particular. Based on the current Happstack Crash Course, I would guess that the canonical libraries[1] for Happstack probably include BlazeHtml and HSX/HSP for templating, web-routes for routing, and acid-state for persistence. Acid-state and its all-haskell persistence philosophy combine with the type-safe routing and templates to create a set of libraries for web development where Haskell's expressive type system is king.
Yesod The next of the big three to hit the scene was Yesod, which released in March of 2010. While Happstack (and later Snap) applications only worked as standalone binaries that were their own web server, Yesod provided FastCGI support which enabled Yesod applications to run on shared hosting where running a standalone web server was not an option. Perhaps Yesod's defining characteristic is its strong emphasis on static type checking for all aspects of the web app enabled by a number of custom DSLs used in different areas. In January 2011, the Yesod team released a new modern web server called Warp sporting the fastest benchmark numbers of any Haskell web server, a title still held today.

Yesod's type safety starts with the Hamlet compile time template language with syntax derived from HAML, a markup language that is lighter than (X)HTML. Hamlet's syntax makes it really simple to put dynamic data in templates while remaining strongly typed. This fits really well with Yesod's type-safe routing DSL that generates links for you. The paradigm is very similar to using Happstack with HSX/HSP and web-routes, but with a custom DSL that is more compact. Yesod has taken things a step further though with their Shakespearean template system which they have used to create Cassius and Julius, two strongly typed compile-time DSLs for generating CSS and Javascript.

In working with this paradigm, Yesod developers observed that some amount of boilerplate code was usually required to accomplish all this type safety. Leveraging the power of TemplateHaskell and quasiquoting, Yesod provides small domain-specific languages with syntax customized to each unique purpose that let you specify your site with very little unnecessary cruft.

Additionally, Yesod created a generalized database library called persistent, which uses these same design patterns to create a DSL for specifying your site's data model and lets you easily use MySQL, PostgreSQL, SQLite, or MongoDB to store your data and interact with it in a type safe manner.

This week Yesod released 1.0 milestone, communicating that they have reached a point where they will be maintaining longer-term API stability and support.
Snap Snap is the youngest of the three frameworks. It went public in May of 2010, two months after Yesod. Its initial release featured a template system called Heist, and the first web server implementation to use the new modern concept of left-fold enumerators, a technique for achieving more predictable space usage than lazy IO. The web server API provides a set of combinators that provides a flexible framework for creating both simple and complex routes. This API is essentially a slimmed down and simplified version of the API that Happstack has been using since the early days of HAppS, and as such it should be fairly straightforward to port applications and libraries between the two.

The Heist template system differs from Hamlet and HSP in that it reads templates at runtime rather than compile-time, essentially thinking of templates as data rather than code. This means that it can't do truly type-safe URLs like the other two, but it enforces a much stronger division between code and view.  It also makes it possible for templates to be reloaded without recompiling the application. Aside from the fact that it allows you to define your own tags dynamically, Heist's template syntax is valid HTML.

More recently, Snap released a component system called Snaplets which is designed to allow web apps to be built from self-contained modular components. The Snaplets API provides a composable way to handle things like built-in filesystem resources and installation, config file support, and in-memory state. Since the release of the Snaplets API, the Snap team and third-party developers have released a number of snaplets providing support for sessions, authentication, database integration, etc. Yesod provides something called subsites that looks similar, and based on Happstack's roadmap it sounds like they will be working on another take on this problem in the future.

Snap's canonical libraries appear to be just Snap and Heist. The Snap web server is actually split out into two separate libraries snap-core and snap-server while the Snaplet API is the umbrella project. Other than that, the Snap team hasn't pledged allegiance to any particular database library so you should be free to use anything.
Conclusion Each of the three frameworks has their own unique perspective. They make different tradeoffs, and have different senses of code aesthetic. There's the tradeoff of static, type-safe, and determined at compile-time versus less type-safe, more flexible, and determined at run-time. There's also the tradeoff of concise custom DSLs versus expressive and powerful combinator libraries. Do you go with a generalized database library that provides unified and necessarily watered-down interface to a number of different backends or tie yourself to a single specific database and leverage its full power? These are not always binary choices either. Each of these tradeoffs may be an axis on which there are several or a continuum of valid points to choose from.

Keep in mind that in most cases, different components of the above frameworks can be mixed and matched to suit your needs.  Hopefully this post paints a clearer picture of the landscape and helps you find the framework (or combination of frameworks) that fits your needs and preferences best.

[1] When I use the term "canonical libraries" in this article I'm talking about what I infer is probably the preference used by the main developers maintaining each web framework, and this is likely to be the direction the framework as a whole moves in with a more holistic solution if it chooses to do so.
Categories: Offsite Blogs

Sublime 2 settings for indenting.

Haskell on Reddit - Thu, 06/12/2014 - 7:58pm

I am having a bit of a hard time getting indentation correctly set for Sublime. It's annoying to have to tab over and then backspace or add spaces to align.

I have installed the packages, and played around with things but nothing seems to work for all cases. Is this a deficiency or Sublime or just a quirk with Haskell?

submitted by blipped
[link] [8 comments]
Categories: Incoming News

cabal - the simple guide

Haskell on Reddit - Thu, 06/12/2014 - 6:52pm
Categories: Incoming News

Troubles installing EclipseFP

haskell-cafe - Thu, 06/12/2014 - 5:25pm
Hi, i'm trying to install eclipsefp. Ubuntu 14.04, ghc 7.6.3, cabal-install 1.20. I did it with a fresh .cabal and .ghc folders. Nothing else was installed. After restarting eclipse it started doenloading and building haskell libs, and stopped with this error: Cabal==1.16.0/installed-c6e..., SourceGraph => Cabal<1.7) rejecting: SourceGraph-0.2, 0.1 (conflict: buildwrapper => Cabal==1.16.0/installed-c6e..., SourceGraph => Cabal<1.5) Backjump limit reached (change with --max-backjumps). Note: when using a sandbox, all packages are required to have consistent dependencies. Try reinstalling/unregistering the offending packages or recreating the sandbox. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

ghc-options: -dynamic in package refused by Hackage

haskell-cafe - Thu, 06/12/2014 - 4:47pm
Hello, what's the recommended way to make a package dynamic? 1. I need to make the executable in my package dynamic otherwise I run into 2. I've set ghc-options: -dynamic in my Cabal file and that solves my issues. 3. I can't upload my package to Hackage, I get a "'ghc-options: -d*' debug flags are not appropriate for a distributed package" error. I hadn't realized -dynamic is for debugging purposes... So is there another way to make my package dynamic and uploadable to Hackage? Or should I just not put the flag in the cabal flag and let my users pass the flag when they install? Thanks! JP
Categories: Offsite Discussion

Simple but slow, and complex but fast Forth emulation [Was: Bang, a drum DSL for Haskell]

haskell-cafe - Thu, 06/12/2014 - 4:27pm
Emulation of a simple subset of Forth in Haskell seems easy. The trick, continuation-passing style, has been known for a long time. The trick underlies `functional unparsing' by Olivier Danvy. (published in JFP in 1998). Chris Okasaki later extended the technique He also noted huge types and slow compilation times. But there is another way. It is far more complex, and far fast. It is used in HSXML, which handles polyvariadic functions with literally thousands of arguments (some of my web pages are long). The following complete code illustrates the idea. {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances, FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-}
Categories: Offsite Discussion

List.or, List.any and List.elem

libraries list - Thu, 06/12/2014 - 3:45pm
Curious on whether I should prefer List.any f over List.or . f I consulted the source code at I found that according to the Report, they are identical, but there are fusion rules for List.any which look like I should prefer it to the said composition. What puzzled me is that later, List.elem x is List.any (x ==) according to the Report, but GHC defines it recursively, *without* fusion rules. I wonder Q1: Should I prefer List.any (x==) then, since it gives opportunity to fusion? Q2: Why is then List.elem defined recursively? Q3: Where is the comment that justifies the taken design decisions?? Cheers, Andreas #ifdef USE_REPORT_PRELUDE any p = or . map p all p = and . map p #else any _ [] = False any p (x:xs) = p x || any p xs all _ [] = True all p (x:xs) = p x && all p xs {-# NOINLINE [1] any #-} {-# NOINLINE [1] all #-} {-# RULES
Categories: Offsite Discussion

Deleting mailing list

haskell-cafe - Thu, 06/12/2014 - 11:26am
I want to delete the mailman mailing list for leksah (leksah< at >, since it is not used anymore and only collects spam. It looks as I can't do this on my own, so I need help. My mails to support< at > didn't produce any response. So I try this for years now. Please! Is someone out there that can help me? Kind regards Jürgen Nicklisch-Franken _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Is there such a thing as a low-level functional language?

Haskell on Reddit - Thu, 06/12/2014 - 11:05am

If not, why not? What might one look like?

submitted by c3534l
[link] [30 comments]
Categories: Incoming News

ANN: io-memoize 1.1

General haskell list - Thu, 06/12/2014 - 10:47am
Have you ever wanted to restrict an IO action such that it could only be invoked once? Now you can with System.IO.Memoize.once (formerly known as ioMemo). Need slightly more complicated logic? (e.g. An IO callback that takes an argument but then only executes the first time around, essentially ignoring the argument the other times it is called.) Leverage the dead simple "write once" Control.Concurrent.Cache api for fun and profit. 1. Create an empty cache with newCache 2. fetch repeatedly from the cache, each time providing a fallback in case it is empty. 3. There is no step 3. Fetching from a Cache is thread safe: only one "fallback" will execute at a time, and after the first successful fallback, the cached value will be set and no other fallbacks will be called.
Categories: Incoming News

Mike Izbicki: Tying the type knot gives us theorems for cheap

Planet Haskell - Thu, 06/12/2014 - 9:13am

In today’s adventure, our hero ghc faces its final challenge: granting parametricity to our lensified Functor, Applicative, and Monad classes. Parametricity is the key to finishing the task of simplifying our type signatures that we started two days ago. At the end we’ll still have some loose ends left untied, but they’ll have to wait for another haskell binge.

summon cthulhu > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE LiberalTypeSynonyms #-} > {-# LANGUAGE ImpredicativeTypes #-} > {-# LANGUAGE ConstraintKinds #-} > import Control.Category > import Prelude hiding ( (.), id, Functor(..), Applicative(..), Monad(..) ) > import Data.Params > import Data.Params.Functor > import Data.Params.Applicative > import Data.Params.Monad tying the value knot

At the value level, tying the knot is a classic technique in Haskell data structures. It let’s us build circular datastructures using self-refrence and lazy evaluation. The classic example is the cycle:

> cycle = x where > x = 0 : y > y = 1 : x

But there can be no direct analogy between tying the knot at the value and type level. This is because tying the knot requires lazy evaluation, which doesn’t make sense for types.

(Idea! Maybe we should just start calling Python a lazily typed language!)

But let’s check out a new type level technique… and if you look at the right angle… and squint just the right amount… then it sorta kinda looks like tying the knot.

tying the type knot

Remember all that fun we had with lensified Functors, Applicatives, and Monads? Our new classes are powerful, but we paid a major price for that power: We gave up parametricity. Parametricity is one of the main properties that makes Haskell code so easy to use and fun to write. Giving it up would be a disaster.

So let’s get it back.

First, we’ll modify our type classes. We’ll need to pass a third parameter to each of them. We’ll call it b. This parameter represents the type at the lens position of our Functor/Applicative/Monad.

> class b ~ GetParam lens tb => Functor' lens tb b where > fmap' :: TypeLens p lens -> (a -> b) -> SetParam lens a tb -> tb > class Functor' lens tb b => Applicative' lens tb b where > pure :: GetParam lens tb -> TypeLens Base lens -> tb > > ap :: ( tf ~ SetParam lens (a -> b) tb > , ta ~ SetParam lens a tb > , a ~ GetParam lens ta > ) > => TypeLens Base lens -> tf -> ta -> tb > class Applicative' lens tfb b => Monad' lens tfb b where > join :: tffb ~ CoJoin lens tfb > => TypeLens Base lens -> tffb -> tfb

Now we can guarantee parametricity when we declare instances of the classes. All we have to do is make sure that the b parameter is a variable and not a type constructor. For example, this is parametric:

instance Functor' (Param_a Base) (Either a b) a

but this is not:

instance Functor' (Param_a Base) (Either Int b) Int

Making our instances parametric is not enough for the type checker. We must prove that all instances will always be parametric. These higher-rank type constraints assert this fact:

> type Functor'' p t = forall a t'. ( t' ~ SetParam p a t, Functor' p t' a ) > type Applicative'' p t = forall a t'. ( t' ~ SetParam p a t, Applicative' p t' a ) > type Monad'' p t = forall a t'. ( t' ~ SetParam p a t, Monad' p t' a )

These type synonym constraints are what I’m calling “tying the type knot.” The foralled a and t’ let us represent an “infinite” number of constraints with a finite size, just like tying the knot lets us represent an infinite data structure with finite memory.

This same technique also works for the constrained monad problem:

> type CnstFunctor p c t = forall a t'. ( t' ~ SetParam p a t, Functor' p t' a, c a ) > type CnstApplicative p c t = forall a t'. ( t' ~ SetParam p a t, Applicative' p t' a, c a ) > type CnstMonad p c t = forall a t'. ( t' ~ SetParam p a t, Monad' p t' a, c a ) simpler type signatures

So what, exactly, do these new parametric constraints buy us?

Remember how we used the idea of type-level rewrite rules to simplify the type of our applicative sequencing operator (*>)? Now we can simplify it even further.

This is the type that we came up with two posts ago:

(*>) :: ( Applicative lens ( SetParam lens ( a -> b -> b ) tb ) , Applicative lens ( SetParam lens ( b -> b ) tb ) , Applicative lens tb , tb ~ SetParam lens b tb ) => SetParam lens a tb -> tb -> TypeLens Base lens -> tb

It’s pretty clean except for the multiple Applicative constraints. But if we use the type-knotted constraints, we can combine all the Applicatives into one:

(*>) :: ( Applicative'' lens tb , tb ~ SetParam lens b tb ) => SetParam lens a tb -> tb -> TypeLens Base lens -> tb

Unfortunately, we can’t test these parametric constraints today because of a ghc bug/missing feature.

giving ghc diabetes

With a heavy dose of sugar, we can use our type lenses to create a type level record syntax. This will make our (*>) operator’s type even clearer… almost like original.

The sugaring rules are pretty simple. Just replace any type expression of the form:

t { lens = a }

with a call to the SetParam type function:

SetParam lens a t

And that’s it!

Now, the lensified and standard versions of (*>) are pretty similar looking. Here they are in a side-by-side comparison:

original (*>) :: Applicative t => t a -> t b -> t b lensified (*>) :: Applicative lens t => t { lens = a } -> t { lens = b } -> t { lens = b }


tying another *kind* of knot

Next time, we’ll see how to promote everything we’ve done to the kind level.

Just kidding!

I’m actually getting married this weekend! I wanted to share my excitement with all you haskellers, so I put together this bad little tying the knot pun! Thanks for putting up with me! Yay!

(disclaimer: there’s probably lot’s of little mistakes floating around in these posts… type theory isn’t really my area… and I just thought of this idea last week… and… now my brain hurts…)

Categories: Offsite Blogs

Haskell Weekly News: Issue 296

General haskell list - Thu, 06/12/2014 - 3:23am
Welcome to issue 296 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from May 25 to June 7, 2014 Quotes of the Week * mbrock: then you get into a whole thing about the epistemology of abstract algebra, and someone brings up Wittgenstein, somebody brings out a bottle of wine, and it's yet another one of those nights Top Reddit Stories * An alternative Haskell home page Domain:, Score: 160, Comments: 57 Original: [1] On Reddit: [2] * Third generation of the attoparsec parsing library Domain:, Score: 82, Comments: 22 Original: [3] On Reddit: [4] * Music-Suite Domain:, Score: 81, Comments: 44 Original: [5] On Reddit: [6] * Erik Meijer: Introduction to Functional Programming Domain: edx
Categories: Incoming News

System.Directory.removeDirectoryRecursive and symlinks

libraries list - Tue, 06/10/2014 - 2:42pm
Hi all, A crime scene: Prelude System.Directory> :!mkdir a-directory Prelude System.Directory> :!touch a-directory/a-file.txt Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory" Prelude System.Directory> :!ls a-directory a-file.txt Prelude System.Directory> :!ls a-symlink-to-a-directory a-file.txt Prelude System.Directory> removeDirectoryRecursive "a-symlink-to-a-directory" *** Exception: a-symlink-to-a-directory: removeDirectory: inappropriate type (Not a directory) Prelude System.Directory> :!ls a-symlink-to-a-directory Prelude System.Directory> :!ls a-directory Prelude System.Directory> :!ls -a a-directory ... Prelude System.Directory> :!ls -a a-symlink-to-a-directory ... Prelude System.Directory> removeDirectoryRecursive is removing all contents *of the directory linked* but is unable to remove the symlink itself. This behavior is surprizing if not dangerous. I understand that this mimics behavior of unlink/rmdir and DeleteFile/RemoveDirecto
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!


Categories: Incoming News