News aggregator

A neat way of doing non-greedy parsing with Parsec.

Haskell on Reddit - Thu, 06/25/2015 - 6:43pm

I recently found a way of parsing a file where I didn't care about large portions of the input. It's quite useful for when you only need to extract some parts of the input but leave the rest untouched. Here's a simplified example:

foo { ... } bar { ... }

Here I just want ("foo", ...) and ("bar", ...) .

This is hard to do in Parsec because it is greedy so the obvious path is wrong.

The non-obvious (to me) solution involved continuously checking the rest of the input past the "don't care" point to see if it was valid.

An unexpected benefit is that it parses unescaped delimiters correctly!

I'm sure it's pretty inefficient, but for me it worked out because the inputs hovered around ~200 lines or so.

Hope it's useful.

submitted by deech
[link] [24 comments]
Categories: Incoming News

Executing a list of shell commands in order

Haskell on Reddit - Thu, 06/25/2015 - 4:17pm

I'm a newbie at Haskell and my first small program reads a list of "features" from a YAML file, does dependency analysis (via fgl) and builds a list of shell commands to execute in the proper order.

All the above works (using little more than a bunch of list comprehensions -- probably terrible Haskell but it works at least!).

However I'm kind of lost now at how to execute my list of shell commands. Obviously it needs to be done in an IO Monad context, and ideally I'd like to have some kind of retry mechanism ("try X three times, if it fails all of them abort, otherwise move on to next command").

Does anybody have any pointers or tips on how to approach this problem?

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

Higher Kinded Void

haskell-cafe - Thu, 06/25/2015 - 3:20pm
Hi all, I currently have some code for which I require a uninhabitable Functor. I currently just use - data VoidF a instance Functor VoidF where fmap = undefined Is there a reason something like this is not in the package void? Perhaps we could even have Void1 with kind * -> *, Void2 with kind * -> * -> * etc. I opened a github issue a few days ago but haven't received a response from ekmett yet -
Categories: Offsite Discussion

If you could change one thing about Haskell, what would it be?

Haskell on Reddit - Thu, 06/25/2015 - 3:04pm

Just to be clear, I'm talking about the language itself, not the ecosystem (GHC, cabal, etc) or the community.

submitted by bitmadness
[link] [203 comments]
Categories: Incoming News

Categorical Visions

Haskell on Reddit - Thu, 06/25/2015 - 3:04pm
Categorical Visions

In this post I want to share my visions of what the future of programming might look like. Why? Dunno, I was bored. This isn't really about Haskell, but lots of people here seem to find related things interesting, so I decided to give it a go. Anyway, here we go, wall of text ahoy!

If you know Haskell, - and I assume you do, since this is /r/Haskell - you know that Haskell borrows things from category theory. However, if you know category theory, you also know that Haskell doesn't borrow very much from category theory. The entire point of this post is to point out how unfortunate it is that there is no programming language designed around category theory.

A Categorical Language

Some languages, such as CHARITY, already claim to be 'categorical'. Why are these not good enough?

The answer to that is simple: they restrict themselves to only a single category. When I'm talking about a categorical language, I'm talking about a language that naturally lets you talk about things in multiple categories, using the internal languages of each in a natural way.

Designing such a language is, of course, going to be extremely hard. I doubt the theory necessary to make a prototype exists yet, so this is not something we will see soon. Still, I believe it is going to be useful.

The motivations for a categorical language starts in monads. Monad has been very useful for modelling side effects in Haskell. This is, however, just the tip of the iceberg. The reason Monad has been useful is that monads give you Kleisli categories: there's a reason the type of most monad-y things in Haskell is a -> b -> ... -> m r. Kleisli categories let you extends Hask with arbitrary effects. Effectively, Monads become language extensions!

Now, it turns out that it is not in every category that monads are useful. You might have already noticed that Arrows don't use monads for effects, they use arrow transformers. In fact, this is not the only way monads are limited. Monads can only express a small subset of the extensions we are interested in.

Enough Theorizing!

Ok, ok, let's get to an example. Let's take the classic Haskell example, Suppose You Are Building A Compiler For Lambda Calculus. Now you need a type to represent ASTs. What do you do?

How about this?

data Term = Var String | Apply Term Term | Lambda String Term

There are many problems with this type. I am not going to talk about them here, but an interesting exercise is to find and fix them. Right now, however, I would like to show what could be:

data Term = Var #name | Apply Term Term | Lambda ([#name] Term)

So, what is #name?

Well, it is the type of names!

What is its members?

Names, of course!

Do you mean strings?

No, the type of names is very different. For example, the type of names has the interesting property that for any thing, you can find a name that is not used in that thing. I will not go into too many details here - look into nominal sets if you are interested - but you might see where I'm getting with this: by choosing the right category - in this case Nom - you can get plumbing written for you. Here, we can automatically know that everything is invariant under name permutations.

Choosing Categories

There are many useful categories that I believe might end up getting used for programming. I will list some of them here, but first a quick note.

The idea with a categorical language is not to have a bunch of built-in categories. That would certainly be... interesting, but I doubt it would work in the long run. Instead, what I envision is the ability to write any category that becomes useful. We might end up with tons of categories (and various combinators to create more powerful categories) that all provide new functionality with nice syntax.

Nice syntax for custom categories is probably an important feature, otherwise this could all be done in, say, Idris, or any other dependently typed functional language.

So, onto the examples. I can't guarantee that all of these examples will turn out to be implementable - some might have laughable performance, be unruly in practice, or I might simply have misunderstood the category and its relation to programming.

  • Linear logic has been used to model protocols. There are many different categories that give rise to various linear logics, but I think there are many that would work really well for protocols.
  • I already mentioned Nom and compilers/interpreters.
  • "Clock variables" have been used to make corecursion more civilized.
  • Various categories have been proposed to model functional reactive programming, but an interesting point is that maybe you could have something similar to arrowized FRP, but with better syntax.
  • You could switch between levels of abstraction without switching programming language: working in a lazy garbage collected category most of the time, but switching to a Rust-like low-level category for high-performance code. Then you can use a functor to throw the Rust-like category into the high-level category.

This is just a small taste of what we could end up with. However, it might make my vision more obvious: you would always be using 'the right tool for the job'.


I should probably mention some of the challenges. First of all, I expect a lot of the theory will come from Directed Type Theory, a spinoff of Homotopy Type Theory where things are directed. This means you are working with infinity-categories instead of infinity-groupoids.

DTT is not the solution though, at least not yet, and I doubt it will ever be. First of all, it is to my knowledge even less fleshed out than HoTT. In addition, while its types represent higher categories, its syntax does not include a way to work internally to these categories. I doubt that will ever happen, as it is not, to my knowledge, the point of DTT to work within other categories.

There are some things about DTT that I like and expect would be in the categorical language. For example, every function is implicitly a functor.

Inventing the categorical language is going to be extremely hard. It has to deal with many tasks, and therefore gets a lot of complexity.

It is well-known that OO languages have complexity in their types due to variances. The categorical language would have similar complexity, as functors can have many variances, the most well-known being co- and contravariant.

To be usable, it needs to have extremely flexible syntax that makes working in every category natural. This is going to be a major complication all the way through the implementation.

I don't know whether it is possible to have this language, but damnit I'm going to try anyway! Well, when I'm not too lazy, which I almost always am.

Minor Goodies

Everyone knows you can't convince people using visions. Actually, that's wrong. Visions are much more convincing than they ought to be. Anyway, there are a couple of nice, though not especially useful, properties with this approach. Let's look at the minor goodies that would make life more satisfying (though not necessarily easier).

  • Every 'normal' type of functor (Functor, Contravariant, Bifunctor, Profunctor, ...) might get unified as just an ordinary function space.
  • Other types of functors (Applicative, Adjoint, ...) could get unified as a hom space in other categories-of-categories.
  • By adopting this language, you would always be using the right tool for the job, which means you are now much more 'pragmatic' than the people who usually complain about lack of pragmatism in FP.

Look at the 'Choosing Categories' section.

submitted by tailcalled
[link] [31 comments]
Categories: Incoming News

"lifted" traversable? i.e. ((f x -> h (g x)) -> (t f a -> h (t g a)))

Haskell on Reddit - Thu, 06/25/2015 - 1:23pm

something like:

traverse' :: ((Applicative h, Traversable' t) => (forall x. f x -> h (g x)) -> (t f a -> h (t g a)))

The effectful function becomes a natural transformation, the kind of t changes from (* -> *) to ((* -> *) -> (* -> *)), and we transform the functors f instead of the as.

maybe like a "hoistA", where:

hoist :: (MFunctor t, Monad m) => (forall a. m a -> n a) -> t m b -> t n b

I couldn't find anything on Google. I'm currently explicitly passing it in to a function, so no big deal. But I wanted to know if any such type class existed with laws and stuff, and that somebody smarter than me like /u/edwardkmett already wrote.

submitted by spirosboosalis
[link] [5 comments]
Categories: Incoming News

Douglas M. Auclair (geophf): Business Interrelations as a Graph

Planet Haskell - Thu, 06/25/2015 - 9:17am
We look at a practical application of Graph Theory to take a complex representation of information and distill it to something 'interesting.' And by 'interesting,' I mean: finding a pattern in the sea of information otherwise obscured (sometimes intentionally) by all the overwhelming availability of data.

We'll be working with a graph database created from biz.csv, so to get this started, load that table into neo4j:
USING PERIODIC COMMITLOAD CSV WITH HEADERS FROM "file:///[...]/biz.csv" AS csvLineMERGE (b1:CORP { name: csvLine.contractor })MERGE (b2:CORP { name: csvLine.contractee })
MERGE (b1)-[:CONTRACTS]->(b2)
We got to a graph of business interrelations this past week (see, e.g.: showing who contracts with whom, and came to a pretty picture like this from the Cypher query:

MATCH (o:OWNER)--(p:PERSON)-[]->(c:CORP) RETURN o,p,c
diagram 1: TMI
That is to say: the sea of information. Yes, we can tell that businesses are conducting commerce, but ... so what? That's all well and good, but let's say that some businesses want to mask how much they are actually making by selling their money to other companies, and then getting it paid back to them. This is not an impossibility, and perhaps it's not all that common, but companies are savvy to watch dogs, too, so it's not (usually) going to be an obvious A -[contracts]-> B -[contracts] -> A relationship.

Not usually, sometimes you have to drill deeper, but if you drill too deeply, you get the above diagram which tells you nothing, because it shares too much information.

(Which you never want to do ... not on the first date, anyway, right?)

But the above, even though noisy, does show some companies contracting with other companies, and then, in turn being contracted by some companies.

So, let's pick one of them. How about company 'YPB,' for example? (Company names are changed to protect the modeled shenanigans)

diagram 2: tier 1 of YPB
So, in this first tier we see YPB contracting with four other companies. Very nice. Very ... innocuous. Let's push this inquiry to the next tier, is there something interesting happening here?


diagram 3: tier 2 of YPB
Nope. Or what is interesting is to see the network of businesses and their relationships (at this point, not interrelationships) begin to extend the reach. You tell your friends, they tell their friends, and soon you have the MCI business-model.

But we're not looking at MCI. We're looking at YPB, which is NOT MCI, I'd like to say for the record.

Okay. Next tier:


diagram 4: tier 3 of YPB
Okay, a little more outward growth. Okay. (trans: 'meh') How about the next tier, that is to say: tier 4?


diagram 5: tier 4 of YPB
So, we've gone beyond our observation cell, but still we have no loop-back to YPB. Is there none (that is to say: no circular return to YPB)? Let's push it one more time to tier 5 and see if we have a connection.


diagram 6: tier 5 with a (nonobvious) cycle of contracts
Bingo. At tier 5, we have a call-back.

But from whom?

Again, we've run into the forest-trees problem in that we see we have a source of YPB, and YPB is the destination, as well, but what is the chain of companies that close this loop. We can't see this well in this diagram, as we have so many companies. So let's zoom into the company that feeds money back to YPB and see if that answers our question.

diagram 7: cycle of contracts from YPB
Aha! There we go. By focusing our query the information leaps right out at us. Behold, we're paying Peter, who pays Paul to pay us back, and it's there, plain as day.

Now, lock them up and throw away the key? No. We've just noted a cyclical flow of contracts, but as to the legality of it, that is: whether it is allowed or whether this is fraudulent activity, there are teams of analysts and lawyers who can sink their mandibles into this juicy case.

No, we haven't determined innocence or guilt, but we have done something, and that is: we've revealed an interesting pattern, a cycle of contracts, and we've also identified the parties to these contracts. Bingo. Win.

The problem analysts face today is diagram 1: they have just too much information, and they spend the vast majority of their time weeding out the irrelevant information to winnow down to something that may be interesting. We were presented with the same problem: TMI. But, by using graphs, we were able to see, firstly, that there are some vertices (or 'companies') that have contracts in and contracts out, and, by investigating further, we were able to see a pattern develop that eventually cycled. My entire inquiry lasted minutes of queries and response. Let's be generous and say it took me a half-hour to expose this cycle.

Data analysts working on these kinds of problems are not so fortunate. Working with analysts, I've observed that:

  1. First of all, they never see the graph: all they see are spreadsheets,
  2. Secondly, it takes days to get to even just the spreadsheets of information
  3. Third, where do they go from there? How do they see these patterns? The learning curve for them is prohibitive, making training a bear, and niching their work to just a few brilliant experts and shunting out able-bodied analysts who are more than willing to help, but just don't see the patterns in grids of numbers
With the graph-representation, you can run into the same problems, but 
  1. Training is much easier for those who can work with these visual patterns,
  2. Information can be overloaded, leaving one overwhelmed, but then one can very easily reset to just one vertex and expand from there (simplifying the problem-space). And then, the problem grows in scope when you decide to expand your view, and if you don't like that expanse, it's very easy either to reset or to contract that view.
  3. An analyst can focus on a particular thread or materialize that thread on which to focus, or the analyst can branch from a point or branch to associated sets. If a thread is not yielding interesting results, then they can pursue other, more interesting, areas of the graph, all without losing one's place.
The visual impact of the underlying graph (theory) cannot be over-emphasized: "Boss, we have a cycle of contracts!" an analyst says and presents a spreadsheet requires explanation, checking and verification. That same analysis comes into the boss' office with diagram 7, and the cycle practically leaps off the page and explains itself, that, coupled with the ease and speed of which these cycles are explored and materialized visually makes a compelling case of modeling related data as graphs.
We present, for your consideration: graphs.

Models presented above are derived from various Governmental sources include Census Bureau, Department of Labor, Department of Commerce, and the Small Business Administration.
Graphs calculated in Haskell and stored and visualized in Neo4J
Categories: Offsite Blogs

Advice gfx library

haskell-cafe - Thu, 06/25/2015 - 8:55am
I am interested in writing some real code now! What i could do with is a gfx library that Can render mpeg/mov files Scale Transform etc Is simple! Runs on windows in some form Ive got hudaks book about multimedia, and understand the general reactive idea behind it....i want to build on top of that Ive nosed around gloss and grapefruit, but the mpeg piece seems missing from these Any ideas? Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are vir
Categories: Offsite Discussion

Promoting associated data types

haskell-cafe - Thu, 06/25/2015 - 7:44am
Good day! DataKinds doesn't allow promotion of type/data families. However, in the specific case of associated data families -- aren't they constrained more, and sufficiently so that the following, for example, could be made to work without stepping into dangerous territories: -- {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UnicodeSyntax #-} module M where class C a where data D a ∷ * data I instance C I where data D I class C1 a (b ∷ D I) where
Categories: Offsite Discussion

Yesod Web Framework: Cleaning up the Warp APIs

Planet Haskell - Thu, 06/25/2015 - 3:00am
Cleaning up the Warp APIs

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