News aggregator

Edward Kmett: CUFP 2014 Call For Presentations

Planet Haskell - Sun, 04/20/2014 - 1:13pm

Workshop for
Commercial Users of Functional Programming 2014
Sponsored by SIGPLAN
[CUFP 2014](
Co-located with ICFP 2014
Gothenburg, Sweden
Sep 4-6
Talk Proposal Submission Deadline: 27 June 2014

CUFP 2014 Presentation Submission Form

The annual CUFP workshop is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work.

Giving a CUFP Talk

If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the workshop. We're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform participants about how functional programming plays out in real-world applications, focusing especially on lessons learned and insights gained. Experience reports don't need to be highly technical; reflections on the commercial, management, or software engineering aspects are, if anything, more important.

Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers.

We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our mission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy.

If you are interested in offering a talk, or nominating someone to do
so, please submit your presentation before 27 June 2014 via the

CUFP 2014 Presentation Submission Form

You do not need to submit a paper, just a short proposal for your talk! There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more a discussion forum than a technical interchange.

Nevertheless, presentations will be video taped and presenters will be expected to sign an ACM copyright release form.

Note that we will need all presenters to register for the CUFP workshop and travel to Gothenburg at their own expense.

Program Committee More information

For more information on CUFP, including videos of presentations from
previous years, take a look at the CUFP website at Note that presenters, like other attendees, will need to register for the event. Presentations will be video taped and presenters will be expected to sign an ACM copyright release form. Acceptance and rejection letters will be sent out by July 16th.

Guidance on giving a great CUFP talk

Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits.

  • Setting: FP is pretty well established in some areas, including formal verification, financial processing and server-sid web-services. An unusual setting can be a source of interest. If you're deploying FP-based mobile UIs or building servers on oil rigs, then the challenges of that scenario are worth focusing on. Did FP help or hinder in adapting to the setting?
  • Technology: The CUFP audience is hungry to learn about how FP techniques work in practice. What design patterns have you applied, and to what areas? Did you use functional reactive programming for user interfaces, or DSLs for playing chess, or fault-tolerant actors for large scale geological data processing? Teach us something about the techniques you used, and why we should consider using them ourselves.
  • Getting things done: How did you deal with large software development in the absence of a myriad of pre-existing support that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community?
  • Don't just be a cheerleader: It's easy to write a rah-rah talk about how well FP worked for you, but CUFP is more interesting when the talks also spend time on what _doesn't_ work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly.
Categories: Offsite Blogs

Is there a package that provides Vectors in the Safe dialect?

Haskell on Reddit - Sun, 04/20/2014 - 10:39am

I've just noticed that Data.Vector cannot be imported in Safe Haskell because it isn't safe itself. In this particular case I mainly want to use vectors as lookup tables, so I'm mostly interested in O(1) random access. Is there a package which provides this and is written in the Safe dialect? Usually I'd just go and use Data.Map (or rather IntMap here), but lookup is O(log n) here which would slow down the algorithm I'm working on from O(n) to O(n log n).

submitted by tsahyt
[link] [7 comments]
Categories: Incoming News

Haskell on FreeBSD

Haskell on Reddit - Sun, 04/20/2014 - 8:08am

How is the Haskell support for FreeBSD? I saw the Haskell Platform is supported. Are there other packages on Hackage that compile for Linux but not FreeBSD?

submitted by riotflowers
[link] [8 comments]
Categories: Incoming News - Sun, 04/20/2014 - 6:45am
Categories: Offsite Blogs - Sun, 04/20/2014 - 6:45am
Categories: Offsite Blogs

Announcing cabal 1.20

Haskell on Reddit - Sun, 04/20/2014 - 5:42am
Categories: Incoming News

Johan Tibell: Announcing cabal 1.20

Planet Haskell - Sun, 04/20/2014 - 5:36am

On behalf of all cabal contributors, I'm proud to announce cabal 1.20. This is quite a big release, with 404 commits since 1.18. To install:

cabal update cabal install Cabal- cabal-install- New features

Since there are 404 commits since cabal 1.18, there are too many changes to give all of them a just treatment here. I've cherry-picked some that I thought you would find interesting.

To see the full list of commits, run:

git log Cabal-v1.18.1.3..Cabal-v1.20.0.0

in the cabal repo.

Dependency freezing

If you're building an application that you're delivering to customers, either as binary or as something that runs on your servers, you want to make sure unwanted changes don't sneak in between releases.

For example, say you've found a bug in the just released version and you want to release, which contains a fix. If you build the binary on a different machine than you built the release on, you risk building it against a slightly different set of dependencies, which means that your introducing untested code into your application, possible causing new bugs.

cabal freeze lets developers of applications freeze the set of dependencies used to make builds reproducible. cabal freeze computes a valid set of package versions, just like cabal install does, and stores the result in cabal.config. You can then check cabal.config into your source control system to make sure that all developers that work on the application build against the exact same set of dependencies.

Here's the contents of the cabal.config file created by running cabal freeze in the cabal-install repo:

constraints: ... HTTP ==4000.2.8, array ==, base ==, bytestring ==, ...

If you later want to update the set of dependencies either:

  • manually edit cabal.config or
  • delete (parts of) cabal.config and re-run cabal freeze.

Note that you should only use cabal freeze on applications you develop in-house, not on packages you intend to upload to Hackage.

Parallel cabal build

Starting with 7.8, GHC now accepts a -j flag to allow using multiple CPU cores to build a single package. This build performance enhancement is now exposed as a -j flag on cabal build (and also cabal test/bench/run). Build time improvements are modest, but free.

Flag to temporary ignore upper bounds

When new major versions of a package P is released, it usually takes a little while for packages that depend on P to update their version bounds to allow for the new version. This can be frustrating if you just want to test if your own package, which depends on both some of these other packages and on P, builds with the new P.

The --allow-newer=P flag tells the dependency solver to ignore all upper version bounds on P, allowing you to try to compile all packages against this newer version.

Unnecessary re-linking avoidance

Before 1.20, cabal would sometimes re-link build targets that hadn't changed. For example, if you had several test suites that tested different parts of your library, every test suite would be re-linked when you ran cabal test, even if no source file that the test suite depends on was changed. The same thing would happen for executables and benchmarks.

Now cabal doesn't re-link executables (of any kind) unless something changed.

Streaming cabal test output

cabal test can now stream its output to stdout, making it easier to see progress for long-running tests. Streaming output is enabled by passing --show-details=streaming to cabal test and is off by default (for now.)

New cabal exec command

Cabal sandboxes have almost completely replaced previous sandbox implementations. There was one use case that wasn't completely captured by the integrated sandbox implementation, namely starting new shells where the environment was set up to automatically use the sandbox for all GHC commands.

cabal exec allows you to launch any binary in an environment where the sandbox package DB is used by default. In particular you can launch a new shell using cabal exec [ba]sh.

Haddock configuration options

Haddock options can now be set in ~/.cabal/config. Here are the options and their default values:

haddock -- keep-temp-files: False -- hoogle: False -- html: False -- html-location: -- executables: False -- tests: False -- benchmarks: False -- all: -- internal: False -- css: -- hyperlink-source: False -- hscolour-css: -- contents-location: How to use cabal

While not strictly related to this release, I thought I'd share how we expect users to use cabal. Using cabal this way makes sure that the features work well for you, now and in the future.

The main message is this: to build a package, use build, not install.

Building packages using cabal install comes from a time when

  • installing dependencies was more difficult,
  • depending on non-published packages was difficult (i.e. no sandbox add-source), and
  • using the other commands required manual configure-ing.

My intention is to remove the need for install from the development workflow altogether. Today the recommended way to build a package is to run this once:

cabal sandbox init cabal install --only-dep # optionally: --enable-tests

The development workflow is then just

cabal build/test/bench/run

No configuring (or manual rebuilding) needed. build implies configure and test/bench/run imply build.

Soon build will also imply the above dependency installation, when running in a sandbox.


Here are the contributors for this release, ordered by number of commits:

  • Mikhail Glushenkov
  • Johan Tibell
  • Duncan Coutts
  • Thomas Tuegel
  • Ian D. Bollinger
  • Ben Armston
  • Niklas Hambüchen
  • Daniel Trstenjak
  • Tuncer Ayaz
  • Herbert Valerio Riedel
  • Tillmann Rendel
  • Liyang HU
  • Dominic Steinitz
  • Brent Yorgey
  • Ricky Elrod
  • Geoff Nixon
  • Florian Hartwig
  • Bob Ippolito
  • Björn Peemöller
  • Wojciech Danilo
  • Sergei Trofimovich
  • Ryan Trinkle
  • Ryan Newton
  • Roman Cheplyaka
  • Peter Selinger
  • Niklas Haas
  • Nikita Karetnikov
  • Nick Smallbone
  • Mike Craig
  • Markus Pfeiffer
  • Luke Iannini
  • Luite Stegeman
  • John Lato
  • Jens Petersen
  • Jason Dagit
  • Gabor Pali
  • Daniel Velkov
  • Ben Millwood

Apologies if someone was left out. Once in a while we have to make commits on behalf of an author. Those authors are not captured above.

Categories: Offsite Blogs

Douglas M. Auclair (geophf): 'M' is for burrito. No, really! (Monads, a burrito-escque introduction)

Planet Haskell - Sun, 04/20/2014 - 2:33am

'M' is for Burrito. No, really.(A little post about monads)
This one's easy.
A monad is a burrito: a nice, soft-shell wrapper hiding all that yummy, but complicated stuff inside (green peppers and onions? who was the first one to think of that?)
A monad is a burrito, wrapping all that complicated stuff like an integer:
Just 3
under its soft-shell wrapper:
I just showed you two monads: the first one is the 'Maybe' monad, representing semideterminism (we're certain, in this case, that the underlying unit is 'Just' 3, but we could, in a different situation, be equally certain that the underlying unit was 'Nothing' Those two cases (two = semi) give us our certainty (determinism) one way or the other), the second is the 'List' monad, representing nondeterminism (you could have the empty list [] (no answers, no = non), or, in the above case, a list with a set of different answers (one or several)).
So, monad = burrito. Simple, right?
Class dismissed.
"Excuse me, Professor geophf," the wormy student in the back of the class wearing b-c glasses and who always has to ask annoying questions in his whiny voice at the very end of class, making everybody late for their next class and me late for my latte, and you don't want to make me late for my latte! He continued, oblivious: "What about monads that don't contain anything at all? What is that? An empty burrito?"
He giggled at his own joke, thinking himself rather smart and drôle.
"What?" I roared, "An empty burrito? Such sacrilege cannot be! Besides, what's the point of an empty monad? That's just ridiculous!"
I was rather peeved that this young upstart would trespass on the beauty of my burrito-analogue. It was simple and easy to understand. Why mess with it?
"But," he continued in his whiny voice, "what about the empty list and 'Nothing' in the Maybe monad. They carry no value but are essential to each of those monads, how do you explain these monadic values as burritos? Are they churros?"
I sputtered in fury. He had me there.
So I did what every <strikeout>tyrant</strikeout>teacher does, I relied on my position of authority.
"No, monads are burritos! Get that through your head!" And then: "Class dismissed!"
Everybody fled. I do cut quite the imposing figure when I have that angry glint in my eye and my flinty face set in stone.
Okay, so monads aren't burritos. I admit it. (But not to Mr. Wormwood. Never, never!) There is nothing that says a monad has to carry a value, it's just a convenience to think of monads like that: a wrapper around an 'ordinary' object. But monads are objects, themselves, and, in fact, more 'ordinary,' that is: regular, than plain-old objects like integers.
The problem of plain-old objects, the problem that monads address, each in their own way (and there are many species of monads, not just maybes and lists, but eithers, and states and ... stuff! Lots of wild and weird different stuff!), is that plain-old objects admit the uninhabited instance, ⊥, in their type. So the type of natural numbers is 0, 1, 2, 3, ... but it's also ⊥. For programming languages that realize this (haskell, for example), they deal with this gracefully. For programming languages that realize this, but then do nothing about it, there is a systemic problem of the program going into an unstable state when encountering an uninhabited instance.
Something that causes Algol-child language programmers to shake in their booties: the 'null-pointer exception.'
Question: how can Java throw a 'NullPointerException,' when it doesn't have the pointer construct in its language, at all? Am I the first to call this one out?
So, the function in these languages that have ⊥ but do not handle it properly must always admit that you're not working with functions at all, for:
x + y
is x plus y, but if either in uninhabited, the answer is KABOOM!
A program crash. You just destroyed your entire system. And you didn't even do it: the language designers did.
Monads were an answer to this problem. A little dude with a long, bushy beard by the name of Kleisli developed the work around what came to be known as the Kleisli categories, that had monads as their objects and (what came to be known as) Kleisli arrows as morphism, or functions.
The guarantee of the Kleisli category was that, indeed, every object as a monad, so there's no uninhabited type, this means Kleisli functions always get you back into a Kleisli category (yes: once you enter the monadic domain, you never leave it. That's the guarantee of a Kleisli category, you can only be a monad (or a monadic function or monad category ...) to get in, and no monads exist outside the Kleisli categories. The monadic domain is the Hotel California of categories).
Okay, you're stuck. And the guarantee of the monad is that you don't care what's under the soft-shell, there's no 'getting a value out' of a monad, because, as my annoying student, Mr. Wormwood, pointed out, there are monads with no underlying values. So what do you do with them?
Monads have a special function associated with them, called the 'join' operator.
Monads, you see, are a special type in that a join of a monad of a monad is just a monad, so, for example,
join (Just (Just 3))
gives you 
Just 3
What does that do for us?
Well, the structure of a monadic function is this:
Monad m ↠ f m :: a → b m
That is, the function takes an ordinary type a and 'lifts' it into the monadic category giving the (monadic) answer of type b (correctly m b, as m is the monadic type and b is the type carried by the monad).
Okay, but monadic functions can't dig out the underlying type in a monad of its category, so how do even the functions work at all?
Just as you can lift an unit type into a monad:
return 3 = Just 3
You can also lift an ordinary function into the monadic domain:
liftM succ = m Int → m Int (for some monadic type m)
Okay, so, but where does that even get us? We're still stuck, right?
Well, the thing is, you can even lift monadic functions into the monadic-monadic domain:
liftM f (of type Monad m ↠ a → m b) = f' :: Monad m ↠ m a → m (m b)
What does that get us?
Well, combining join with a lifted monadic function gets us a monad from monadic input:
join (liftM f (Just 3)) = some monadic answer dependent on the resultant type of f.
This whole lifting-into-the-monadic-domain-and-then-joining-the-result is so common when working in monad categories that a special operator was invented, à la Haskell, named '>>=' (pronounced: 'bind').
Now, with bind the true power of monads come out:
m >>= f >>= g >>= h >>= ... etc.
What you see here a monad being bound, in turn, to the monadic functions f, g, h, etc.
So, okay, you've got a short-hand for monadically binding functions together. Great. Good on you, and have a latte.
The thing here is this.
In 'plain-old' programming, you have this ever-present fear that a NullPointerException is going to ruin your life, so you can't write:
getting an A from obj, then getting a B from that A, then getting a C from that B, then you do something with that C.
I mean, you can write that code, but if any of those objects are null: obj, A, B, C, your whole statement explodes?
No, worst than that: your entire system blows up, and you have to deal with irate customers wondering why they got a 505-Service down error when they submit their credit card information but forgot to enter their zip code, or some such.
So you have to wrap that statement in a try-block, and try it and see if it works, and if it doesn't you have this whole envelope, this whole burrito shell of code you have to write to handle the uninhabited case.
Now let's look at the monadic function binding again:
m >>= f >>= g >>= h >>= ... etc.
What happens if m is null, or the result of f m is ...
No. Wait. Monads don't have nulls. Monads are just monads, so the above binding ...
... okay, wait for it, ...
In fact, in the Kleisli category, it is guaranteed to work.
It. just. works.
For you, not a Java(script) programmer, you're like: "Well, duh, yeah, that's how it's supposed to be! 1 + 1 = 2, not 'error' or whatever."
You can say that, and expect that, in a pure mathematical domain (with monads implicit in the mathematics for you. You're welcome.) But a Java programmer, with any experience, any hard-won experience should be (rightly) awed.
"Wait. You mean, it just works? How is that possible?"
Yeah. How is that possible? That Java code just works?
It doesn't. But, when I translate the Kleisli category down into a Java implementation, and then lift every Java object into that cateogy, so it's not a Plain-old Java Object (POJO) any more, but now it's a monad in the Kleisli category, and operate on it as such from then on.
Well, then, it just works.
Some people look at my monadic harness and say I'm unnecessarily complicating things.
I beg to differ.
"But, geophf, I just want the start date; all this stuff just complicates things!"
But what do you want the start date ... for? If you just want the start date, then
will get you there, and you're done.
But if you want to base any logic off it? Is your start date the start of a work-flow? So if the start date is null, your system, that you unit tested with start date values, now crashes in production and you have no idea why, because you unit tested it, and the code looks good.
But that one null wrecks everything.
I don't have any nulls. So I lift my start date up into a monad, and start my work flow, and my work flow works, and if the start date is null, then the start date isn't lifted, the functions fall through, because they're not working with a monad, and I just go onto the next thing.
And I coded zero lines of code around that.
Your try-catch blocks looking for nulls everywhere ...
Well, what's more complicated now? What code works in production, regardless of dirty or bad data?
Monads are a guarantee, and, as burritos go, they are quite tasty. Give them a try!


Now there's the whole conversation around monads that carry no value intentionally throughout the entire monad. So, for example, if the monad type is 'Quark' the the monadic inhabited types are up, down, strange, charmed, top and bottom, and their values are ... nothing at all: their instance is the value, it has no underlying value it carries (unless you want to get into the guts of spin and charge ...), its the particular monad instance, or the particular quark, we care about, not what's inside at all, something like monads as enumerated values, but ... eh. Monads-as-burritos is a limited view, it will trip you up, but for the most part it works. When you do get to the point of treating monads-as-monads, and not caring, anymore, about the underlying value, you can tap yourself on the shoulder with monadic-Nirvana. It's a really good feeling, and gives an entirely new understanding of monads and their utility. "Good to know," as it were, but monad-as-burrito works for the most part and is tasty, too, to boot.
Categories: Offsite Blogs

Douglas M. Auclair (geophf): 'O' is for ontology.

Planet Haskell - Sun, 04/20/2014 - 2:09am

'O' is for Ontology.
What is an ontology? A knowledge-base? Sure, if that's simpler to grasp, but only insofar as 'knowledge-base' doesn't mean 'collection of facts' or 'data set.'
An ontology is more than that. But what, precisely, is an ontology?
Well, actually, there is a precise meaning to 'ontology.' And 'meaning,' itself, is central to ontology. Because what does these data mean is what an ontology is about. It's not a listing of facts, but it's also the relationship of the facts in the ontology that makes it what it is. The data, the facts, of an ontology have meaning, not only intrinsically, but also explicitly, or: the meaning is useable, or can be processed, itself, as information, and used in the handling of the underlying information.
An ontology? Absolutely! You hand that to your husband, and he knows exactly what it is and he knows exactly how to use it. He even, helpfully, penciled in the missing item (ho-hos, just as a 'fer instance') onto your shopping list for you.
Now, ontology, per se?  Not so much. But if you explicitly titled it "Shopping List," now you're talking!
Format it as XML or JSON or OWL and then your computer will do your shopping for you, just as well as your husband would.
Even better, as it won't add those pesky ho-hos your husband always 'helpfully' adds to your list for you.
Your computer does need arms and legs and artificial intelligence, but I'm sure Cyberdyne Systems will be happy to help you there ... and also hand your terminator that was a computer a fully automatic plasma rifle.
Whoopsie! Better give your husband the list, and live with the ho-hos ... Ho-hos are, relatively speaking, better than global thermonuclear war and the extinction of all mankind.
But I digress.
As always.
Categories: Offsite Blogs

Douglas M. Auclair (geophf): 'P' is for Predicate

Planet Haskell - Sun, 04/20/2014 - 2:08am
Hey, all, 'P' day.

'P' should be for π, but that's redundant, right? since π (pronounced 'pee' in math circles) is just the letter 'p' in Greek.

And it's 3.141592653589793238462643383279502884196939937510582097494459230

Yeah, ... I memorized that in high school. For real. People didn't believe me. Every time. So I'd recite it for them, after I wrote it down on a piece of paper so they could verify that I wasn't just spouting digits.



So, but, this post is not about π.

No. Wait. Stop using 22/7 to represent π. That's, like, way off. Way. Use 355/113 instead. And thank Chuck Moore whenever you do.

Okay, done with that aside. Onto this post. This post is about the predicate.

So, what's a predicate?

A predicate is a statement of truth, that you arrive at from other predicates.

Yeah, math and logic are like that: a thing is a thing from other things just like it. Take 'number' for example, any number, x, is just all the previous numbers before x with some starter seed (usually zero or some other representation of null).

Well, that's what a predicate is.

First of all, a predicate is more than a proposition. A proposition is something that you've been seeing already in the alphabet-soup I've been writing, so the proposition for the type of the continuation function is:

(p → r) → r

So, this says, 'given a function that takes a p and gives an r, I can get you an r,' right? Remember that?

Well, a predicate is of this form:

p |- q

Or, if you're feeling your Prolog:

p :- q

A p is true, depending on whether q is true.

(Here we go again with dependent types).

So, what's the difference? I mean, if you just reverse the arrows you could say you have:

q → p

And you could say that, but there is a difference, in that the propositional logic of

p → r

Is all very deterministic whereas the predicate logic of

p :- q

is all very non-deterministic. Predicate logic allows you to base the truth of your consequence on none, one, or several conditions.

So, you could have:

p :- q, r, s.

Which means that p is true if q and r and s are all true, as well.

These are universals, but you can get specific with it, too:

p(x) :- q(x, y), r(y, z).

Which says that there is some x in p, giving a truth, dependent upon the same x in q (associated with some y) being true, along with the same y in r being true with some z.

And, to prove that statement you have to find the (x, y, z) values that satisfy the conditions of that statement. And you keep looking until you find it.

What does that sound like? ... We'll get back to that in a moment.

The neater thing about predicate logic is that the clauses of a predicate can, themselves, be consequences of other predicates:

q(x, y) :- s(y), t(x)
r(a, b) :- t(a), w(b)

And predicates can have multiple statements to arrive at that truth:

q(1, 2).
q(2, 4).
q(3, 6).

The above is saying: "q(1, 2) is true, regardless of anything." And you can take that truth (that fact) and plug it in anywhere. The fact propagates throughout the system.

So, those three facts, along with the relation, q(x, y) :- s(y), t(x), form a predicate. A statement of truth throughout the system, covering all possibilities.

A predicate is a program.

Yeah. Wow.

In Java or Haskell or Ruby a program is thousands, tens of thousands of lines, but in a logic programming languages, like Prolog, for example, a program could be one line or several ... more than a few lines, actually, and you're going off the deep end. And how you program in Prolog is that you string these predicates, these programs, together to create an Universe of related truths, an ontology, in which you can ... play, by which I mean, you can query the system, get an answer (if there is one) or get back several answers, and explore this Universe you've created, or that someone has created for you, as an inquiry into truth.

*Sigh* I miss coding in Prolog. When done neatly, it was so neat to use.

But I don't miss coding in Prolog. It was all dynamically typed, so you could put in anything for your inquiry, and it would try it out, looking for the string "Mama meetzaballs!" even though this particular predicate is about arithmoquines. And I don't miss it for the fact that statements of fact were easy to formulate, but the functional constructs ... ugh, they were terrible.

I need me a programming language that does logic typefully and handles functional logic beautifully, like Haskell does. Maybe ... Idris? ... but Idris doesn't work on my decade-old laptop. Birthday present for moi, then?

Categories: Offsite Blogs

JSON validation combinators

Haskell on Reddit - Sun, 04/20/2014 - 1:21am
Categories: Incoming News

Bartosz Milewski | FP Complete - Sat, 04/19/2014 - 10:44pm
Categories: Offsite Blogs

Gabriel Gonzalez: How the continuation monad works

Planet Haskell - Sat, 04/19/2014 - 10:32pm

I remember the first time I read the Monad instance for ContT I was so confused. I couldn't fathom how it worked because it was hard to discern the pattern.

However, I later discovered that renaming things makes the pattern much more clear:

import Control.Applicative

newtype ContT x m r = ContT { (>>-) :: (r -> m x) -> m x }

instance Functor (ContT x m) where
fmap f m = ContT $ \_return -> -- fmap f m =
m >>- \a -> -- m >>= \a ->
_return (f a) -- return (f a)

instance Applicative (ContT x m) where
pure r = ContT $ \_return -> -- pure r =
_return r -- return r

mf <*> mx = ContT $ \_return -> -- mf <*> mx =
mf >>- \f -> -- mf >>= \f ->
mx >>- \x -> -- mx >>= \x ->
_return (f x) -- return (f x)

instance Monad (ContT x m) where
return r = ContT $ \_return -> -- return r =
_return r -- return r

m >>= f = ContT $ \_return -> -- m >>= f =
m >>- \a -> -- m >>= \a ->
f a >>- \b -> -- f a >>= \b ->
_return b -- return b
Categories: Offsite Blogs

Request: What to read for reification/hylomorphisms?

Haskell on Reddit - Sat, 04/19/2014 - 9:02pm

Reification into an intermediate data structure is often a neat little trick. Tree sort, where you foldl' and insert elements into a tree then flatten the tree is a neat little technique. Ornamented zippers for traversing trees makes it possible to pretend you have a tail recursive function.

What other interesting solutions are there that reify some computational structure into an intermediate data structure?

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

Is there a way to modify the default implementation of Show?

Haskell on Reddit - Sat, 04/19/2014 - 8:13pm

I've got a complicated ADT, and want to be able to show it. The default implementation obtained from deriving Show on it is close to what I want, but I want different behavior on one of the (many) constructors the ADT has. Is there a way of telling Haskell "use the default implementation except for this one case which should be done differently," or do I need to write the whole thing out by hand?

This is an example of roughly what I'm aiming at:

data Foo = First Int Int | Second String Int | Third [Bool] String | Fourth Int Int Int | Fifth String | Sixth Foo Foo | Seventh Foo String | ... | Twentieth String [Bool] deriving Show

I'd like Foo's implementation of show to have the default behavior except that Twentieth shouldn't display its list of Bools. Is there a simpler way of doing this than writing the whole thing myself?

edit: made Foo recursive, as my actual ADT is recursive, too.

submitted by penguinland
[link] [20 comments]
Categories: Incoming News - Sat, 04/19/2014 - 7:46pm
Categories: Offsite Blogs - Sat, 04/19/2014 - 7:46pm
Categories: Offsite Blogs