News aggregator

Yesod Web Framework: Cleaning up the Warp APIs

Planet Haskell - Thu, 06/25/2015 - 3:00am

For the last one and a half years, I have been trying to implement HTTP/2 in Warp. Since both HTTP/2 implementations of Firefox and Chrome requires TLS for HTTP/2, I'm also trying to improve the performance of WarpTLS. In the process, I need to change the Connection data type. I felt nervous a bit because Connection is exported from the top module, Network.Wai.Handler.Warp. I believe there are only two users of this data type: Warp itself and WarpTLS. Normal users do not use it. So, Connection should be exported from the Internal module. This motivated me to clean up the Warp APIs.

The APIs of Warp 3.0 has the following issues:

  • The top module exports many internal APIs which are prone to change.
  • The Internal module does not export enough internal APIs.

Michael and I decided to clean up the Warp APIs. The following changes will be made in the version 3.1:

  • Already deprecated APIs (settingsFoo) are removed from the top module.
  • In the documentation of the top module, each API is categorized into either standard or internal.
  • The Internal module exports all internal APIs including the internal APIs in the top module.
  • Stopping exporting the Buffer and Timeout module which have been exported from the top module.

The standard APIs of the top module mainly consist of high-level run functions, Settings related stuff and necessary data types. We try to maintain these stably.

The internal APIs in the top module will be removed in Warp version 3.2. This is just documented. DEPRECATED pragmas are not added since there is no simple way to make an API deprecated in the top moudle but live in the internal module.

Warp version 3.1 is not released yet but is available from github repository. We will wait for a week or two to hear users' opinions.

Categories: Offsite Blogs

Abstract behavior and instance selection at runtime

Haskell on Reddit - Thu, 06/25/2015 - 2:01am

(stackoverflow related question)

I usually use class / instance to define certain abstract behavior but I fall in troubles trying to select one instance at runtime.

On related stackoverflow question I was adviced to avoid class / instance and use "the record way" (a great post here).

Then, I've written a little example but I don't know if is correct (I'll fall in troubles again :D).

Thank you any comment or suggestion!

{-# LANGUAGE Rank2Types #-} import System.Environment import Control.Applicative import Control.Monad.IO.Class import System.Random import Control.Monad -- Certain behavior with state (updatable) data Behavior m a = Behavior { behaviorName :: String , behaviorUpdate :: m (Behavior m a) , behaviorCurrent :: m a } -- Counter example data CounterBehavior a = CounterBehavior a counterToBehavior :: (MonadIO m, Num a) => CounterBehavior a -> Behavior m a counterToBehavior (CounterBehavior c) = Behavior "Counter" update current where update = return $ counterToBehavior $ CounterBehavior (c + 1) current = return c -- Random example data RandomBehavior a = RandomBehavior randomToBehavior :: (MonadIO m, Random a) => RandomBehavior a -> Behavior m a randomToBehavior r = Behavior "Random" update current where update = return $ randomToBehavior r current = liftIO randomIO -- Selecting and running behavior at runtime main = do n <- (read . head) <$> getArgs let behavior :: Behavior IO Int behavior = case n of 0 -> counterToBehavior (CounterBehavior 0) _ -> randomToBehavior RandomBehavior putStrLn $ "Updating and showing using `" ++ behaviorName behavior ++ "`:" foldM_ (\b _ -> do b' <- behaviorUpdate b a <- behaviorCurrent b' putStrLn $ " - Updated to " ++ show a return b' ) behavior [100..105] {- > :set args 1 > main Updating and showing using `Random`: - Updated to -4106126820688342533 - Updated to 7286196435097841291 - Updated to -8197253363690799377 - Updated to 5677894391788214088 - Updated to 3743905895909972289 - Updated to -1051968694166484490 > :set args 0 > main Updating and showing using `Counter`: - Updated to 1 - Updated to 2 - Updated to 3 - Updated to 4 - Updated to 5 - Updated to 6 -} submitted by j0sejuan
[link] [3 comments]
Categories: Incoming News

Haskell support in Apache Spark (I am preparing)

haskell-cafe - Wed, 06/24/2015 - 11:10pm
I am researching how to do. Hence, now is the time for everybody speak(!!) so I don't get blindsided, e.g. "I already did that" or "I am already working on that". Bad mojo. Vasili _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

On typing very generic terms.

Haskell on Reddit - Wed, 06/24/2015 - 6:27pm

This term:

nTuple = (t -> (t (b c d -> (b (e -> (c e d)))) (b -> b) (b -> b))

On the pure untyped lambda calculus is very useful since it allows us to create constructors for n-tuples. Using → as "normalizes to", and (a,b,c...) as a syntax sugar for tuples ((a b c t → (t a b c...)), and number literals as church numbers, we can do, for example:

-- creates the constructor for a 4-tuple nTuple 4 → (a b c d t -> (t (a b c d))) -- creates a pair with 7, 8 nTuple 2 7 8 → (7,8)

We can also generically write getters, setters and lenses for those tuples. For instance, the term

nTupleGetter = (a b t -> ((b (d e -> d) (d -> (b (e f g -> (e (h t -> (t (h f))) (h -> g) (h -> h))) (e f -> (e (a e f))) (e f -> e) d d))) (d -> d)))

receives the size of the tuple and an index, and returns a getter for that index for that tuple length. For example:

pair = nTuple 2 fst = nTupleGetter 2 0 snd = nTupleGetter 2 1


fst (pair 1 2) → 1 snd (pair 1 2) → 2

That sounds extremely useful, but none of those functions is typeable on System-F. And that isn't just about tuples. Look at this zip definition:

zipWith = (a b c d e -> (b (f g t -> (t (f g))) (f -> e) (c (f g h i -> (d (a h f) (i g))) (f g -> e))))

It works as you'd expect. Using [x,y...] as syntax for church-lists (c n → (c x (c y ...)),

zipWith pair [1,2,3] [4,5,6] → [(1,4),(2,5),(3,6)]

What is interesting about this function is that it is not only total, but extremely efficient. It uses no recursion (no Y-combinator or similar there), so inlining is possible and it fuses by mere normalization. For example, the function below multiplies each element of 2 lists pairwise, and then sums the resulting list:

zipAddSum = (a b -> (foldr add 0 (zipWith mul a b))

Now, lets look at its normalization:

zipAddSum → (a b -> (a pair (c -> 0) (b (c d e f -> (add (mul e c) (f d))) (c d -> 0))))

Notice how the normalized function only traverses each list only once. add and mul got fused together on the inner loop for free. This function, too, isn't typeable on System-F. Those (and many, many other) terms are very useful, but I would like to use them in a typed setting. How can I do this? Can dependently typing handle those? Is there any type system that makes that simple - even inferable? Would I have to write "proofs" and spend a lot of time figuring out the types? How could that work, at all?

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

NY Haskell Meetup live streaming tonight

Haskell on Reddit - Wed, 06/24/2015 - 2:48pm

The NY Haskell Meetup recently got access to live streaming equipment and will be streaming the tonight's meetup at 7pm New York time. Since the equipment is supplied by the venue and this is only the second time we've been able to use the system we can't guarantee that it will work, but we will try our best. When the meetup starts we will post a link to the live stream here.

If you are interested in watching live with us or if you think it's not worth the effort, please let us know so we can get an idea of whether this is something we should continue in the future.


Update 2: If you have a question you would like asked, post it here and we'll try to get them asked at the end.

submitted by mightybyte
[link] [9 comments]
Categories: Incoming News

Reinventing the wheel with HList.

haskell-cafe - Wed, 06/24/2015 - 1:59pm
My latest confusion.... I've got a typeclass (with associated types) monoid sort of thing.... I can get a Singleton family of Nat to be an instance of the typeclass. Lists are sort of Natural numbers...with a bit of extra functionality... So I should be able to take HList and make that a member of the same typeclass... I fail for 2 reasons...1...I have to wrestle with the a way I find ununderstandbly irritating. And 2...because BOOM. "is a rigid type variable bound by" blab la. My Haskell in many ways is primitive...I seem to be messing with things beyond my ability....but that's the way to learn I suppose. Define something like a monoid over the types... (note I have to wrestle with the kind signatures to get the instance of SNat to work, which is fine...but now closes doors to other instances) And this works quite nicely Now.... (I have to declare different kind?....I can't get a single simple declaration of TMonoid?) Steal the definition of HList And try to construct an a
Categories: Offsite Discussion

Is it possible to install linux specific Haskell package under Cygwin?

Haskell on Reddit - Wed, 06/24/2015 - 12:38pm

I'm using Windows 8.1, and I have installed Cygwin. I want to particularly install the unix and hdevtools. Is it possible to install them through Cygwin? I tried installing the unix package with Cygwin, but I got an error message saying it is not supported in my system, though in the docs it says that it works under Cygwin. Any ideas?

submitted by HighCode
[link] [2 comments]
Categories: Incoming News

Why is stack not cabal?

Haskell on Reddit - Wed, 06/24/2015 - 11:54am
Categories: Incoming News

Binary Sum

Haskell on Reddit - Wed, 06/24/2015 - 9:34am

i need tips to make a sum with two binary numbers, the right way to do it, i guess its coverting to two complements binary.

submitted by chocsx
[link] [4 comments]
Categories: Incoming News

Generalizing a library

haskell-cafe - Wed, 06/24/2015 - 9:30am
Hi Cafe! I've written very first version of GHCJS port <> of Perch <> library originally designed to work with Haste compiler. Most of work is already done, though some polishing is needed. In essence Haste and GHCJS versions are very similar, the major difference is how foreign functions are defined, and in fact Perch is built using just a few low-level primitives <>. So, as these libraries are very similar I want to generalize Perch to make it independent of compiler somehow. My initial idea was to have a Perch library and several compiler specific back-ends which user should select depending on his toolchain, but my Haskell skills are still very poor to find a proper way to do this. Can someone point me in right direction or at least give some advices? Very appreciate any help! _______________________________________________ Haskell-Cafe mailing list
Categories: Offsite Discussion

FP Complete: Why is stack not cabal?

Planet Haskell - Wed, 06/24/2015 - 7:00am

This blog post is intended to answer two very frequest questions about stack: how is it different from Cabal? And: Why was it developed as a separate project instead of being worked on with Cabal?

Before we delve into the details, let’s first deconstruct the premises of the questions. There are really three things that people talk about when they say “Cabal”:

  1. a package metadata format (.cabal files) and specification for a “common architecture for building applications and tools”, aka Cabal-the-spec,
  2. an implementation of the spec as a framework, aka Cabal-the-library,
  3. cabal-install, aka Cabal-the-tool, which is a command-line tool that uses Cabal-the-library.

Stack complies with Cabal-the-spec, both in the sense that it groks .cabal files in their entirety and behaves in a way that complies with the spec (insofar as that is relevant since the spec hasn’t seen any updates in recent years). In fact it was easy for Stack to do, because just like Cabal-the-tool, it is implemented using Cabal-the-library. Therefore, a first answer to the questions at hand is that stack is Cabal: it is 100% compatible with the existing Cabal file format for specifying package metadata, supports exactly the same package build harnesses and is implemented on top of the same reference implementation of the spec as cabal-install, which is just one tool among others using Cabal-the-library. cabal-install and stack are separate tools that both share the same framework. A successful framework at that: Haskell’s ecosystem would not be where it is today without Cabal, which way back in 2004, for the first time in the long history of Haskell made it possible to easily reuse code across projects by standardizing the way packages are built and used by the compiler.

Stack is different in that it is a from-the-ground-up rethink of Cabal-the-tool. So the real questions are: why was a new tool necessary, and why now? We’ll tackle these questions step-by-step in the remainder of this post:

  • What problem does stack address?
  • How are stack’s design choices different?
  • stack within the wider ecosystem
The problem

Stack was started because the Haskell ecosystem has a tooling problem. Like any number of other factors, this tooling problem is limiting the growth of the ecosystem and of the community around it. Fixing this tooling problem was born out of a systematic effort of growth hacking: identify the bottlenecks that hamper growth and remove them one by one.

The fact that Haskell has a tooling problem is not a rumour, nor is it a fringe belief of disgruntled developers. In an effort to collect the data necessary to identifying the bottlenecks in the growth of the community, FP Complete conducted a wide survey of the entire community on behalf of the Commercial Haskell SIG. The results are in and the 1,200+ respondents are unequivocal: package management with cabal-install is the single worst aspect of using Haskell. Week after week, Reddit and mailing list posts pop up regarding basic package installation problems using cabal-install. Clearly there is a problem, no matter whether seasoned users understand their tools well, know how to use it exactly right and how to back out gracefully from tricky situations. For every battle hardened power user, there are 10 enthusiasts willing to give the language a try, if only simple things were simple.

Of a package building and management tool, users expect, out-of-the-box (that means, by default!):

  1. that the tool facilitates combining sets of packages to build new applications, not fail without pointing to the solution, just because packages advertize conservative bounds on their dependencies;
  2. that the tool ensures that success today is success tomorrow: instructions that worked for a tutorial writer should continue to work for all her/his readers, now and in the future;
  3. that invoking the tool to install one package doesn’t compromise the success of invoking the tool for installing another package;
  4. that much like make, the UI not require the user to remember what previous commands (s)he did or did not run (dependent actions should be run automatically and predictably).

In fact these are the very same desirable properties that Johan Tibell identified in 2012 and which the data supports today. If our tooling does not support them, this is a problem.

Stack is an attempt to fix this problem - oddly enough, by building in at its core much of the same principles that underlie how power users utilize cabal-install successfully. The key to stack’s success is to start from common workflows, choosing the right defaults to support them, and making those defaults simple.

The design

One of the fundamental problems that users have with package management systems is that building and installing a package today might not work tomorrow. Building and installing on my system might not work on your system. Despite typing exactly the same commands. Despite using the exact same package metadata. Despite using the exact same version of the source code. The fundamental problem is: lack of reproducibility. Stack strives hard to make the results of every single command reproducible, because that is the right default. Said another way, stack applies to package management the same old recipe that made the success of functional programming: manage complexity by making the output of all actions proper functions of their inputs. State explicitly what your inputs are. Gain the confidence that the outputs that you see today are the outputs that you see tomorrow. Reproducibility is the key to understandability.

In the cabal workflow, running cabal install is necessary to get your dependencies. It's also a black box which depends on three pieces of global, mutable, implicit state: the compiler and versions of system libraries on your system, the Cabal packages installed in GHC’s package database, and the package metadata du jour downloaded from Hackage (via cabal update). Running cabal install at different times can lead to wildly different install plans, without giving any good reason to the user. The interaction with the installed package set is non-obvious, and arbitrary decisions made by the dependency solver can lead to broken package databases. Due to lack of isolation between different invocations of cabal install for different projects, calling cabal install the first time can affect whether cabal install will work the second time. For this reason, power users use the cabal freeze feature to pin down exactly the version of every dependency, so that every invocation of cabal install always comes up with the same build plan. Power users also build in so-called “sandboxes”, in order to isolate the actions of calling cabal install for building the one project from the actions of calling cabal install for building this other project.

In stack, all versions of all dependencies are explicit and determined completely in a stack.yaml file. Given the same stack.yaml and OS, stack build should always run the exact same build plan. This does wonders for avoiding accidentally breaking the package database, having reproducible behavior across your team, and producing reliable and trustworthy build artifacts. It also makes it trivial for stack to have a user-friendly UI of just installing dependencies when necessary, since future invocations don’t have to guess what the build plan of previous invocations was. The build plan is always obvious and manifest. Unlike cabal sandboxes, isolation in stack is complete: packages built against different versions of dependencies never interfere, because stack transparently installs packages in separate databases (but is smart enough to reuse databases when it is always safe to do, hence keeping build times low).

Note that this doesn’t mean users have to painstakingly write out all package versions longhand. Stack supports naming package snapshots as shorthand for specifying sets of package versions that are known to work well together.

Other key design principles are portability (work consistently and have a consistent UI across all platforms), and very short ramp-up phase. It should be easy for a new user with little knowledge of Haskell to write “hello world” in Haskell, package it up and publish it with just a few lines of configuration or none at all. Learning a new programming language is challenge enough that learning a new package specification language is quite unnecessary. These principles are in contrast with those of platform specific and extremely general solutions such a Nix.

Modularity (do one thing and do it well), security (don’t trust stuff pulled from Internet unless you have a reason to) and UI consistency are also principles fundamental to the design, and a key strategies to keeping the bug count low. But more on that another time.

These have informed the following "nice to have" features compared to cabal-install:

  • multi-package project support (build all packages in one go, test all packages in one go…),
  • depend on experimental and unpublished packages directly, stored in Git repositories, not just Hackage and the local filesystem,
  • transparently install the correct version of GHC automatically so that you don’t have to (and multiple concurrently installed GHC versions work just fine),
  • optionally use Docker for bullet-proof isolation of all system resources and deploying full, self-contained Haskell components as microservices.

The technologies underpinning these features include:

  • Git (for package index management),
  • S3 (for high-reliability package serving),
  • SSL libraries (for secure HTTP uploads and downloads),
  • Docker,
  • many state-of-the-art Haskell libraries.

These technologies have enabled swift development of stack without reinventing the wheel and have helped keep the implementation stack simple and accessible. With the benefit of a clean slate to start from, we believe stack to be very hackable and easy to contribute to. These are also technologies that cabal-install did not have the benefit of being able to use when it was first conceived some years ago.

Whither cabal-install, stack and other tools

Stack is but one tool for managing packages on your system and building projects. Stack was designed specifically to interoperate with the existing frameworks for package management and package building, so that all your existing packages work as-is with stack, but with the added benefit of a modern, predictable design. Because stack is just Cabal under the hood, other tools such as Halcyon for deployment and Nix are good fits complement stack nicely, or indeed cabal-install for those who prefer to work with a UI that they know well. We have already heard reports of users combining these tools to good effect. And remember: stack packages are cabal-install packages are super-new-fangled-cabal-tool packages. You can write the exact same packages in stack or in another tool, using curated package sets if you like, tight version bounds à la PVP if you like, none or anything at all. stack likes to make common usage easy but is otherwise very much policy agnostic.

Stack is a contributor friendly project, with already 18 contributors to the code in its very short existence, several times more bug reporters and documentation writers, and counting! Help make stack a better tool that suits your needs by filing bug reports and feature requests, improving the documentation and contributing new code. Above all, use stack, tell your friends about it. We hope stack will eliminate a documented bottleneck to community growth. And turn Haskell into a more productive language accessible to many more users.

Categories: Offsite Blogs

Cabal cannot resolve dependencies for my Yesod website

libraries list - Wed, 06/24/2015 - 5:07am
Hello, all, I am trying to make the next big thing with Yesod -- but for now, just a Hello World website. After getting it running locally, I tried to integrate it with Circle CI, which has support for cabal-based Haskell projects. Circle CI runs the following commands: cabal sandbox init cabal install --upgrade-dependencies --constraint="template-haskell installed" --dependencies-only --enable-tests With this invocation, cabal cannot resolve dependencies no matter how I change the cabal config. If, however, I run just `cabal install`, everything works. This cabal failure occurs both on a CircleCI host and my laptop exactly the same way, so I know it's not my environment. I wrote a StackOverflow question with more details: The github repo, for ease of reproducing the problem: I hope that someone on the list is able to help. Thanks.
Categories: Offsite Discussion

Jade for Haskell

Haskell on Reddit - Wed, 06/24/2015 - 1:36am

Does anyone know of a Jade interpreter in Haskell?

I have a server for my site written in go that uses Amber templates (Amber is go's version of Jade, which is from nodeJS and a port to PHP). Since the site is full of files of that format, I want to create a Haskell server that will serve them just like the go server does. Trying to see if one is better than the other.

submitted by raguay
[link] [10 comments]
Categories: Incoming News


haskell-cafe - Tue, 06/23/2015 - 6:24pm
Announcing stack, a new build tool, first stable release. More information at:
Categories: Offsite Discussion