# News aggregator

### problem installing postgreSQL-libpq on Windows

### ICPE 2017 - 1st Call for Papers

### This non-exhaustive pattern match seems exhaustive

### SPLASH'16: 2nd Combined Call for Contributions toCollocated Events

### How to spot Monads, Applicatives ...

### ANN: eccrypto, aka Hecc, hF2

### ANN: eccrypto, aka Hecc, hF2

### Help with Data.Conduit.List.mapAccum

### wren gayle romano: Off to NYC for July 4th and LICS

Over the last few weeks I was interviewed for the Identity Function. The process was quite nice and got me thinking on a number of things. Some of them I may well flesh out into blog posts once I get the time. Of course, that likely won't be until the autumn given everything else going on the next couple months.

I'll be in ** New York from 28 June through 10 July**. The first couple days are for a PI meeting, then I'll get a four-day weekend before LICS, NLCS, and LOLA. Originally the plan was to take a quick trip to Sacramento that weekend for a friend's wedding. (The wedding's still on, but plans changed.) At least this way I'll get a chance to relax, rather than running all over the place. Of course this also means I'll be spending the 4th in NYC. Historically the 4th has been one of my favorite holidays, because it was one I've always spent with friends. I don't know that any of my readers are in NYC, but if you'll be around drop me a line. Or if you used to live there and know fun things to do that weekend, let me know! (Especially any quiet end-of-Pride things.)

Me and L set the date for our final move to the Bay Area: 20 July. And then I start at Google on the 25th. Between now and then: dissertating!!

comments

### 2nd Call for Papers: OCL and Textual Modeling Tools and Textual Model Transformations (OCL 2016) - Submit Your Paper Until July 17, 2016

### 2nd Call for Papers: OCL and Textual Modeling Tools and Textual Model Transformations (OCL 2016) - Submit Your Paper Until July 17, 2016

### [ANN] Budapest Haskell Hackathon 2016, 6-7th Aug 2016

### JTRES 2016, Submission Deadline Extended to July 3

### [ANN] Budapest Haskell Hackathon 2016, 6-7th Aug 2016

### Christopher Allen: How to use UUID values with Persistent and Yesod

Some people find it trickier to store UUID values in their database with Persistent or to use UUID values in a Yesod web application than is really necessary. Here I’ll share some code from my work that demonstrates some patterns in applications that use Persistent or Yesod which should make it easier.

The context for this post can be found in these two links:

Replying to: Jezen Thomas writing about using UUIDs in Yesod

Prior art: Michael Xavier on UUID columns in Persistent

Alternate title: Same as the original, but with: “and no Control.Lens needed” tacked on.

This code is adapted from stuff we’ve written at work.

Persistent / UUID integration InstancesRadioactive dumping ground for orphan instances. Adding the instances makes Persistent understand how to serialize and deserialize the UUID type. The orphans can be avoided if you use a newtype.

-- Note we're taking advantage of -- PostgreSQL understanding UUID values, -- thus "PersistDbSpecific" instance PersistField UUID where toPersistValue u = PersistDbSpecific . B8.pack . UUID.toString $ u fromPersistValue (PersistDbSpecific t) = case UUID.fromString $ B8.unpack t of Just x -> Right x Nothing -> Left "Invalid UUID" fromPersistValue _ = Left "Not PersistDBSpecific" instance PersistFieldSql UUID where sqlType _ = SqlOther "uuid" ModelsThis is where we actually use the UUID type in our models.

module MyCompany.DB.Models where share [mkPersist sqlSettings,mkMigrate "migration"] [persistLowerCase| User json sql=users email Email sqltype=text UniqUserEmail email uuid UUID sqltype=uuid default=uuid_generate_v4() UniqUserUuid uuid deriving Show Read Eq Typeable |]We use the default JSON representation generated so that the format is predictable for the datatypes. I was a little queasy with this initially and it does mean we have to watch what happens to Aeson, but I believe net-net it reduces defects that reach production.

Yesod PathPiece integrationPathPiece is the typeclass Yesod uses to deserialize Text data into a more structured type, so that something like the following:

!/#Subdomain/#NumberedSlug SomeRouteR GETcould work. Here Subdomain and NumberedSlug are domain-specific types we made to represent a *concept* in our application in a type-safe manner. PathPiece often goes unnoticed by people new to Yesod, but it’s good to understand. For a super simple example:

The PathPiece class itself isn’t terribly complicated or interesting:

-- https://hackage.haskell.org/package/path-pieces-0.2.1/docs/Web-PathPieces.html -- S for "Strict" class PathPiece s where fromPathPiece :: S.Text -> Maybe s toPathPiece :: s -> S.TextTo address the original post’s code, I wouldn’t have written that myself. I generally keep DB/IO stuff apart from things like forms. Partly this is because our web app repository is separate from our domain types / DB stuff repo, which sort of forces us to refactor things we might need to do more than once, or in a context that isn’t a web app. The use of applicative style and the double-lifting was not idiomatic.

Alternate title rejected for being too snarky: I told the doctor it hurts when I move my arm a certain way. The doctor told me to stop moving my arm like that.

I know this site is a bit of a disaster zone, but if you like my writing or think you could learn something useful from me, please take a look at the book I've been writing with my coauthor Julie. There's a free sample available too!

Posted on June 15, 2016

### Reminder: 10 days to submit talks to CUFP 2016

### Douglas M. Auclair (geophf): May 2016 1Liners

**One-liners**

- May 24th, 2016:

Given f :: a -> [a] -> b, g :: a -> c

Write h :: c -> [c] -> b, point-free, in terms of f and g

where h x y = f (g x) (map g y) - May 16th, 2016: The next 3 #1Liner are of a piece, using

data CmpV a =

Vec { len :: Int, top :: a, elts :: [a],

cmp :: CmpV a -> CmpV a -> Ordering } - Give the point-free definition of:

twoVs :: CmpV a -> CmpV b -> ([a], [b]) - instance Ord (CmpV a) where

compare v1 = uncurry (cmp v1) . (v1,)

Make compare point-free by removing v1 from above definition - An Ord-instance needs an Eq-instance:

instance Eq a => Eq (CmpV a) where

v1 == v2 = elts v1 == elts v2

point-free-itize (==) - May 16th, 2016: You have the following lambda:

\x y -> x == y || fn x y

where fn :: a -> a -> Bool

Point-free-itize - obadz @obadzz without any fancy uses of the (a ->) Applicative :)

curry $ foldr (||) False . flip map [(==), fn] . flip uncurry - obadz @obadzz with fancy use of (a ->) Applicative :)

curry $ liftA2 (||) (uncurry (==)) (uncurry fn) - Noah Luck Easterly @walkstherain

curry $ uncurry (||) . (uncurry (==) &&& uncurry fn) - May 5th, 2016:

sames :: Eq a => [a] -> [a] -> Int

Counts equal values at the same indices in two lists.

What is the point-free definition?- joomy @cattheory

sames = curry (length . filter (uncurry (==)) . uncurry zip) - bazzargh @bazzargh and then Fatih Karakurt @karakfa

((length . filter id) .) . zipWith (==) - me: sum <<- fromenum="" li="" nbsp="" zipwith="">
- Noah Luck Easterly @walkstherain

sames = ((sum . map fromEnum) .) . zipWith (==) - `getSum . foldMap (Sum . fromEnum)` seems better than `foldr (bool id succ) 0` but both satisfy `[Bool] -> Int`
- Андреев Кирилл @nonaem00

let it = (length .) . (filter id .) . zipWith (==)

- joomy @cattheory

### Roman Cheplyaka: Predicting a coin toss

I flip a coin and it comes up heads. What is the probability it will come up heads the next time I flip it?

“Fifty percent,” you say. “The coin tosses are independent events; the coin doesn’t have a memory.”

Now I flip a coin ten times, and ten times in a row it comes up heads. Same question: what is the probability it will come up heads the next time?

You pause for a second, if only because you are not used to getting heads ten times in a row.

But, after some hesitation, you convince yourself that this is no different from the first experiment. The coin still has got no memory, and the chances are still 50-50.

Or you become suspicious that something is not right with the coin. Maybe it is biased, or maybe it has two heads and no tails. In that case, your answer may be something like 95% for heads, where the remaining 5% account for the chance that the coin is only somewhat biased and tails are still possible.

This sounds paradoxical: coin tosses are independent, yet the past outcomes influence the probability of the future ones. We can explain this by switching from frequentist to Bayesian statistics. Bayesian statistics lets us model the coin bias (the probability of getting a single outcome of heads) itself as a random variable, which we shall call \(\theta\). It is random simply because we don’t know its true value, and not because it varies from one experiment to another. Consequently, we will update its probability distribution after every experiment because we gain more information, not because it affects the coin itself.

<figure> </figure>Let \(X_i\in\{H,T\}\) be the outcome of \(i\)th toss. If we know \(\theta\), we automatically know the distribution of \(X_i\):

\[p(X_i=H|\theta)=\theta.\]

As before, the coin has no memory, so for any given \(\theta\), the tosses are independent: \(p(X_i \wedge X_j|\theta)=p(X_i|\theta)p(X_j|\theta)\). But they are independent only when conditioned on \(\theta\), and that resolves the paradox. If we don’t assume that we know \(\theta\), then \(X\)s *are* dependent, because the earlier observations affect what we know about \(\theta\), and \(\theta\) affects the probability of the future observations.

A model with conditionally independent variables is called a Bayesian network or probabilistic graphical model, and it can be represented by a directed graph as shown on the right. The arrows point from causes to effects, and the absence of an edge indicates conditional independence.

Based on our evidence of 10 heads in a row, the Bayes’ theorem lets us estimate the distribution of \(\theta\). All we need is a prior distribution – what did we think about the coin before we tossed it?

For coin tossing and other binary problems, it is customary to take the Beta distribution as the prior distribution, as it makes the calculations very easy. Often such choice is justified, but in our case it would be a terrible one. Almost all coins we encounter in our lives are fair. To make the beta distribution centered at \(\theta=0.5\) and low variance, we would need to set its parameters, \(\alpha\) and \(\beta\), to large equal numbers. The resulting distribution would assign non-trivial probability only to low deviations from \(\theta=0.5\), and the distribution would be barely affected by our striking evidence.

<figure> </figure>Instead, let’s engineer our prior distribution from scratch. Double-sided coins may be rare in everyday life, but they are easy to buy on eBay. When someone approaches us out of the blue and starts flipping coins, there’s a fair chance they’ve got one of those. Still, we believe in humanity, so let’s assign a point probability of just \(1\%\) to \(\theta=0\) and \(\theta=1\). What about biased coins, such as coins with \(\theta=0.83\)? Turns out they are unlikely to exist. Nevertheless, the Bayesian statistics teaches to be reluctant to assign zero probabilities to events, since then no amount of evidence can prove us wrong. So let’s take \(0.1\%\) and spread it uniformly across the interval \([0;1]\). The remaining \(97.9\%\) will be the probability of a fair coin.

Formally, our prior distribution over \(\theta\) can be specified by its probability density as

\[ p(\theta)=0.979\delta(\theta-0.5)+0.01\delta(\theta)+0.01\delta(\theta-1)+0.001, \]

where \(\delta\) is the Dirac delta function used to specify point probabilities.

Let \(D\) refer to the event that \(X_i=H\), \(i=1,2,\ldots,10\). Then \(p(D|\theta)=\theta^{10}\). By Bayes’ theorem,

\[ p(\theta|D)=\frac{p(D|\theta)p(\theta)}{\int_0^1 p(D|\theta)p(\theta)d\theta} = \frac{\theta^{10}p(\theta)}{\int_0^1 \theta^{10}p(\theta)d\theta}. \]

Now we need to do a bit of calculation by hand:

\[ \begin{multline} \int_0^1 \theta^{10}p(\theta)d\theta=0.979\cdot0.5^{10}+0.01\cdot 1^{10}+0.01 \cdot 0^{10} + 0.001\int_0^1 \theta^{10}d\theta \\ = 9.56\cdot 10^{-4} + 0.01 + 9.09\cdot 10^{-5}=0.0110; \end{multline} \] \[ p(\theta|D)=0.087\delta(\theta-0.5)+0.905\delta(\theta-1)+0.091\theta^{10}. \]

Thus, we are \(90.5\%\) sure that the coin is double-headed, but we also allow \(8.7\%\) for pure coincidence and \(0.8\%\) for a biased coin.

<figure> </figure> <figure> </figure>Now back to our question: how likely is it that the next toss will produce heads?

\[ \begin{multline} p(X_{11}=H|D) = \int_0^1 p(X_{11}=H|D,\theta)p(\theta|D)d\theta = \int_0^1 \theta \, p(\theta|D)d\theta \\ = 0.087\cdot 0.5+0.905\cdot 1+0.091\cdot \int_0^1\theta^{11}d\theta = 0.956. \end{multline} \]

Very likely indeed. Notice, by the way, how we used the conditional independence above to replace \(p(X_{11}=H|D,\theta)\) with \(p(X_{11}=H|\theta)=\theta\).

Bayesian statistics is a powerful tool, but the prior matters. Before you reach for the conjugate prior, consider whether it actually represents your beliefs.

A couple of exercises:

- How does our prior distribution change after a single coin toss (either heads or tails)?
- How does our prior distribution change after ten heads and one tails?

### Package takeover (also: the future of Netwire)

### Philip Wadler: Naomi Klein: The Best is Yet to Come

Amidst all the bad news, Naomi Klein shines a ray of light.

Taken together, the evidence is clear: The left just won. Forget the nomination—I mean the argument. Clinton, and the 40-year ideological campaign she represents, has lost the battle of ideas. The spell of neoliberalism has been broken, crushed under the weight of lived experience and a mountain of data.

What for decades was unsayable is now being said out loud—free college tuition, double the minimum wage, 100 percent renewable energy. And the crowds are cheering. With so much encouragement, who knows what’s next? Reparations for slavery and colonialism? A guaranteed annual income? Democratic worker co-ops as the centerpiece of a green jobs program? Why not? The intellectual fencing that has constrained the left’s imagination for so long is lying twisted on the ground. ...

Looking beyond this election cycle, this is actually good news. If Sanders could come this far, imagine what a left candidate who was unburdened by his weaknesses could do. A political coalition that started from the premise that economic inequality and climate destabilization are inextricable from systems of racial and gender hierarchy could well build a significantly larger tent than the Sanders campaign managed to erect.

And if that movement has a bold plan for humanizing and democratizing new technology networks and global systems of trade, then it will feel less like a blast from the past, and more like a path to an exciting, never-before-attempted future. Whether coming after one term of Hillary Clinton in 2020, or one term of Donald Trump, that combination—deeply diverse and insistently forward-looking—could well prove unbeatable.