I find I’m using the java.net.URI class quite a bit these days. It has two good features: first, it follows the relevant RFCs to the letter; and second, it’s immutable.

The downside of this class is the API - it’s very, well, Java. Actually, it’s bad even by contemporary Java standards. Lets say we wanted to add an argument to the query string of an existing URI. Here’s how you might do it in Java (transliterated to Scala):

Ugh, that’s going to get old fast. And of course, this primitive string appending probably won’t do what you want if the original URI already had a “foo” argument.

If we were to implement URI in Scala, we’d probably use a case class, in which case the compiler would give us a free copy method to help out with this kind of thing. But we can add a copy method to java.net.URI without too much trouble. Let’s do away with all the null and -1 unpleasantness while we’re at it:

Less boilerplate, but still not great. There’s many ways we’re could improve on this, but I’m going to focus on what I think is the best tool for this job: asymmetric lenses.

A Java programmer could intuitively think of an asymmetric lens as the functional programming version of a bean property, without the mutability nightmares. A Scala programmer could think of it as a scalable version of the copy method. An asymmetric lens is basically a means to work with fields within immutable records. I’m using the terms “field” and “record” in a very general sense, the “field” could be a particular key in a “record” that is dictionary map, for example. A lens reifies the mechanics of reading a writing a field into a composable value. As I will attempt to demonstrate, it is the composability of lenses that makes them so powerful.

In the post I’m just going to cover how lenses can help us with a particular example problem. For more details on what they are and how they work, I highly recommend this paper by Tony Morris. It uses Scala and is very easy to follow. All the code from this post, as well as the lens implementation it uses can be found in this gist.

Defining a lens is pretty straight-forward: you provide a function to read the relevant field, and a function to set the field. As we’re talking about immutable records, “setting” a field means returning a new record which has the new value for the field. Unfortunately, this step tends to require a lot of boilerplate in plain Scala. But as we’ll see, you at least only need to do the boilerplate once. There has been some work done to automate much of the boilerplate via compiler plugins or macros, but I haven’t tried these out yet.

So lets define some lenses for the fields of the java.net.URI class. I’m calling the type of my asymmetric lens @> as I think it looks quite nice with infix notation. You read it as “record_type @> field_type”:

This is using the copy method listed above. As I said, this very boilerplatey, but now we’ll never have call the copy method ever again. The Lens constructor takes two arguments: the first is simply a function to return the field value given an instance of the record, and the second is a curried function taking a field value and a record value, and producing a new record value. All of these particular lenses return an optional value, simply because each element of a URI is optional (an empty string is a valid URI!).

Hmm, not really an improvement over the copy method, is it? But we can do better. Let’s make another lens for the query string, but this time we’ll parse the query string to make a URI @> Map[String, String]:

This avoids having to manipulate strings or manually copy objects, and if the query string already has a “foo” argument, its value will simply be replaced. Let’s do the comparison for removing a query string argument:

/** * Java version of removing query argument "foo", if it is present. */defremoveFooArgJava(u:URI):URI={valre="foo=([^&]+)&?".r.patternvalmatcher=re.matcher(if(u.getQueryeqnull)""elseu.getQuery)valnewQuery=matcher.replaceFirst("")newURI(u.getScheme,u.getAuthority,u.getPath,if(newQuery.isEmpty)nullelsenewQuery,u.getFragment)}defremoveFooArgLens(u:URI):URI={lens.query>=>mapLens("foo")set(u,None)}

And naturally, this new “foo” lens can be composed with others. So if, say, the URI was the field of some other case class, all you have to do is define a lens for that field and then compose it with whatever you need, for example:

finalcaseclassExample(href:URI,// more fields)valhrefLens:Example@>URI=Lens(_.href,v=>_.copy(href=v))valexample=Example(newURI("…"))valexampleWithFoo:Example=hrefLens>=>lens.query>=>mapLens("foo")set(u,Some("bar"))

I really hope the Scala team can one day include lenses in the Scala standard library. Scala’s motto is “a Scalable language”. Well, the copy method definitely doesn’t scale well:

And in real code, record/field hierarchies can get a lot more complex than this.

There’s more cool stuff that can be done with lenses. A partial asymmetric lens can be convenient for manipulating values that may be absent. And lenses work really well with the state monad. See the above referenced paper for details.

Other articles

The more I use the Play Web Framework, the more I like it. The “dev mode” is great, compiling everything that’s changed on the fly, including the statically checked routes and templates. But sooner or later we want to deploy our app for reals.

The dist target will package up your app into a zip file with a simple shell script to launch it. That’s fine as far as it goes, but of course I want to run it as a proper service that starts automatically when the machine boots and can be easily shutdown and restarted. My ...

Do you get referential transparency? I mean, really get it? I thought I did, but I recently gained a deeper appreciation for what it means.

Referential transparency is also commonly referred to as “pure” functional programming. I understood this to mean that the code lacked side effects like performing I/O or mutating state, and this seems to be a common understanding. But referential transparency can actually be defined quite precisely and succinctly (although I believe agreement with this definition would be far from universal):

If replacing expression x by its value produces the same behaviour, then x is referentially ...

So it so happened that Ten News was on the T.V. at our place tonight (this is in Melbourne, Australia). Nothing remarkable until a story about 150 doctors issuing a warning that same-sex marriage poses “health risks”. The group behind this is called Doctors For The Family, which calls itself a “medical organisation to highlight the health aspects of marriage”. Ten just described them as “a conservative medical group”, a term that to me seems nonsensical. But I immediately thought “I bet it’s a Christian fundamentalist front”.

Watching the Kony 2012 phenomenon unfold has been interesting. I’ve come to the conclusion that while the people behind they campaign are well-meaning, its not really useful or helpful. In other words, it’s pretty typical of campaigns to “raise awareness” these days.

It is a rather sad indictment on our mainstream media though. Kony 2012 did not reveal any facts that have not been public knowledge for some time. But get a slick and somewhat emotionally manipulative video to go viral and media outlets are suddenly falling over themselves to show their moral cred by promoting it. But ...

I’m going to attempt to explain my position on climate change, mostly for my own benefit, perhaps. The controversial and divisive nature of the climate change debate means that a staggering amount is written about it on a daily basis. What can an amateur like me hope to contribute that hasn’t been better covered elsewhere? I shall attempt to offer a useful perspective. But doing this right means doing it long, so sorry about that.

My Road to “Denial”

For most of my adult life, I have believed that human pollution of the atmosphere was causing destructive changes ...

A chap named ittayd has written a nice gentle tutorial on functional programming in Scala. My only minor complaint is that he calls the applicative functor “sequential application” function apply. While this is a logical choice, in Scala apply is used everywhere to implement plain old function application, so it could lead to confusion. I think it’s better to call it <*>, as in Haskell. Read on.

I found the tutorial interesting because it talks a bit about applicative functors, and how to give them a nice syntax in Scala. The one thing that has bugged me about applicatives is ...

I’ve been using Scala’s Either type a bit recently, and found a
couple of minor annoyances with it. So as a learning exercise I tried to
make a variation of Either, and this is what I came up with. I also
wanted to experiment with syntax a little. See what you think.

Either is a disjunctive type with two possible values: a left and a right.
It places no meaning at all on left or right, but 99% of its uses in practice
involve putting normal, expected values in right, and errors or other
“exceptional” values in left ...

A couple of days ago, Gavin King announced that he is leading a team at RedHat that’s creating a new JVM language called Ceylon. See here for most of what is known so far. The stated motivation, in a nutshell is that they like Java very much, but it has deficiencies that are preventing progress in key areas, and they are generally feeling “frustrated”. They don’t have a complete compiler yet, but they’re working on it, and I get the impression RedHat is pretty serious about it.

I’ve noticed this more and more: people lumping “climate change denial” and “evolution denial” (creationism) into the same category. The argument is that both of these are the result of the same religious conservative “anti-science” movement. In a very narrow sense, this is true; creationists generally do not seem to believe in anthropogenic global warming (AGW), for the same bogus reasons they don’t believe in evolution. But the reverse is not true: many (most I would say) AGW skeptics are not creationists. Lumping these two things together allows the environmentalists to dismiss any criticism of the established climate ...

Whither the Mouse?

Since its inception in 1984, the Mac user interface has obviously been
designed for desktop computers with a mouse and a keyboard. When notebook
computers came along and we wanted to be able to use them without carrying a
mouse everywhere, or without even a flat, stable surface to put the mouse on,
they had to emulate the mouse as best they could. This may now be reversing.

In the announcement of Mac OS X Lion, there was great
emphasis placed on the ...

So Apple has quietly announced that it is deprecating its support for Java on the Mac. The wording was (not uncharacteristically for situations like this) a bit vague on the details of what this means. I think two things are definite: 1) Apple will continue to support Java 6 on Snow Leopard until it reaches end of life; which I think happens when the OSafter Lion is publicly released. 2) Apple will not port Java 7+ to the Mac. The main unresolved question is whether Java 6 will be supported on Lion. My guess is that it will be ...

I’ve been writing more and more pure functional code in both Scala and Java
recently. An issue I found myself running into quite often is this: say you
have a function that sometimes returns no results (e.g. looking up a key in a
map). A common way to deal with that in Scala is to return an Option:

deffoo(i:Int):Option[String]

Simple enough. But then a typical use of such a function is to map it over all members of a collection:

So here’s the deal - if you want to write a Mac GUI app, you want to use the Cocoa framework. As a practical system for writing desktop GUI apps, the Cocoa stack simply has no equal anywhere. Part of what makes Cocoa so great is the Objective-C language, which adds a very flexible and dynamic OOP system on top of standard C.

Objective-C turned out to be a great match for creating desktop GUIs. It’s obviously a general-purpose language, but for general programming it would be no where near my first choice. My first choice right now would ...

Daniel Jalkut, a leading light of the Mac developer community recently blogged about the GPL and some of consequences of it for collaborative software development. I agree with what he says, and I dislike how the GPL limits collaboration in a number of ways. But I thought it might be useful to go over the background and objectives of the GPL.

There’s an important thing to remember when talking about the GPL: the impact, good or bad, on the practicalities of software development have nothing to do with its objectives. The authors of the GPL, the Free Software Foundation ...

Project Euler is a bunch of mathematical/programming problems. I’ve been trying to improve my Scala skills by using it on some of the Euler problems. I’m trying to use functional programming styles as much as possible. My solutions definitely haven’t been very optimized, but I am learning, which is the aim.

The problem with this is that even when the logger’s level is above FINEST and the message is not logged, the message string must still be constructed. In cases where constructing the string involves a lot of work, your code can be slowed down significantly even when logging is off. The standard solution is like so:

Ever get the feeling that XML sometimes makes things harder than they need to be? One of the problems that I and others have run into is that when parsing XML using SAX (or, in my case, using JAXB to unmarshall XML, which uses SAX under the hood) from an InputStream, the stream is always closed after the parsing is complete. This is surprising behaviour in Java, because you’re not supposed to close streams you don’t own. This can be a problem when using network sockets or when you want to write two or more unrelated XML documents ...

Doing cloning properly in Java is way harder than it should be. I thought I knew all the traps, but recently found yet another. In a nutshell, making inner classes cloneable is almost always a bad idea. The reason is that inner classes have an internal reference to an instance of their enclosing class, which is implicitly final and can’t be changed as part of a clone. For example:

This sucker is thrown whenever you invoke a method via reflection (typically via Method.invoke), and that method throws any sort of exception. So it doesn’t indicate a problem with the reflection mechanism, it is simply how the reflection mechanism notifies you of exceptions thrown by the method you called.

Whenever you catch this exception (and you will have to catch it at some level), the first thing you should do is call getCause(). This returns the exception thrown from the method that was invoked via reflection, and that’s ...

This is usually done because the “stuff” throws more than one kind of checked exception, and the code to handle each case is the same. So what’s wrong with it? The biggest problem is that this not only catches the checked exceptions you’re interested in, but also all RuntimeExceptions. The vast majority of RuntimeExceptions are only thrown from buggy code, and catching them ...