## February 2nd, 2008

### flip id

I saw some Haskell code that used the expression `flip id` . What's that do?

`id` is the identity function -- just returns its argument, so it has type `a → a` .
`flip` converts a two-arg function to one that takes its args in the other order -- so, thinking it through, that's type `(a → b → c) → (b → a → c)` (the parens on the right side aren't necessary but they add clarity.

Those are straightforward enough -- but how do you flip a one-argument function? Let's just make the types work out. Start with `id`:
`id :: a → a`
Substitute in a hypothetical function of type `x → y` in for `a`. (I chose new letters to make it less confusing -- too many "a"s flying around already.)
`id :: (x → y) → (x → y)`
Now remove the unnecessary parens on the right (since → is right-associative):
`id :: (x → y) → x → y`
We now have a function that could be interpreted as having two arguments!

Now let's stick that into `flip`. `flip`'s `a` is now `x → y`, its `b` is `x`, and its `c` is `y`, so:
`flip :: (a → b → c) → (b → a → c)`
`flip id :: (x → (x → y) → y)`
And remove the unnecessary parens:
`flip id :: x → (x → y) → y`

And now with the type we can derive the function. Let's call it `flipid`:
`flipid x f = f x`
And that is a simple function: it takes an argument and a function and calls the function with the argument. You could read it as flipping the implicit application operator; in fact, it has the same type as `flip (\$)`, which really is flipping the application operator.

But after all that I'm still not sure I would've come up with that on my own... ah, Haskell, no matter how much I learn there are always simple yet surprising corners. (Some other observations that might have helped: `id f x = f x`; `f `id` x = f x`. Or, looking back, that `id` is the application function, as evidenced by my two-arg form of `id`.)

### a better use for sha1 URLs

[Here's an old thought I never posted; dumping it here as I clean up my home directory. I never posted it before because I thought I ought to look at existing work in this space before I start feeling too creative -- this seems obvious enough to exist already. Whatever.]

If I use an image, I (in some circumstances, at least) want the display to break if the image changes. If I source an image off of someone else's site and use ("steal") it for my MySpace background, I'd rather see a broken image link than goatse when they notice where their bandwidth is going.

Images don't use the fragment part of their URLs. Let's say from now on I reference images with URLs containing like this:
`<img src='http://example.com/foo.png#sha1=012312103120321'>`
And then my browser could regard image data that don't have that SHA-1 as a broken image.

Additionally, my browser could implement a cross-site cache of image data. If there are two references to different URLs with the same SHA-1, it only needs to be loaded once. A browser with this functionality could even work with images like
`<img src='#sha1=012312103120321'>`
which means "pull from cache if you have it, otherwise I give up". In some sense, then, the fragment becomes the real identifier of the image, while the rest of the URL is a hint as to one source to get the image data from.