Matt Hellige / blog

These two books, long ago separately pre-ordered, arrived from different places on the same day:

One of the things keeping me busy lately has been a Haskell reading group, which has mostly amounted to me teaching some people Haskell, using this book as the main text. We've been using the web preprint, and it's exciting to see the real thing!

The first two days of JavaOne have been precisely as expected. Big, silly, lots of hype. But there's been some good stuff as well. The big hype efforts this year seem to be around JavaFX and Glassfish. I don't care about JavaFX at all, and as far as I can tell, nobody really does. But my sample is surely biased. Glassfish looks like a good direction, but we've all seen Spring and OSGI, so I think it's a fairly obvious direction at this point. There's also lots of hype about the JVM running on all kinds of devices, but so what?

In my last post, I translated the first part of Data types a la carte into Scala. I decided to push ahead into the next section, just for fun. The summary is: Scala's implicits are a very poor man's type classes, at least using the obvious encoding, and I am as always humbled by the cleverness of GHC.

I apologize for what you're about to see...

As a little experiment, I decided to translate part of this pearl from Haskell to Scala. By this I mean literal translation, as opposed to an idiomatic implementation in Scala. Of course, this goes deeply against the grain of the Scala language. On the other hand, as I wrote here:

It certainly cuts across the grain of current practice, and the grain of the libraries. But I think it takes a long time to discern the grain of a language. And I think it takes a lot of pushing and prodding, which is why I think this kind of experimentation is so important.

For now, it's a reasonable default to stick to a style that reflects the origins of the language (mostly Java-style OO with some functional goodies and richer types). I definitely think we should be open to the possibility that Scala style will diverge more radically from this tradition.

At this point, I'd probably replace the word "important" with "fun and maybe sort of worthwhile." Anyway, let's get started...

(This is the last of these, I promise.)

In my last post, I described a direct translation of Parsec's permutation parser combinators into Scala. I described one major problem with that approach: the need to provide a fully curried handler function. I suggested that a fix might be possible, and indeed it is. I've produced a new version of these combinators that does not require such a function.

A recent thread on the Scala list raises the question of parsing permutations using parser combinators. This is a situation where parser combinators offer a substantial improvement over EBNF. David Pollak proposes a solution, but it suffers from two problems:

• we are only able to parse permutations where all elements have the same type.
• the results are returned in input order, rather than declaration order, leaving us to figure out how to distinguish them.

Neither of these is disaster, but I hope it's possible to do better.

I've gotten a couple of questions about Hibernate and Scala. My last posts weren't really intended as a "gentle introduction" or anything: my goal was to document a difficulty I had with a particular situation. So here's more of an overview.

Happy new year!

There's been several threads on the Scala list about syntax, and in particular a lot of hating on the /: and :\ methods as shorthands for foldLeft and foldRight. I understand the concerns about overuse of meaningless glyphs, but:

• I think this concern is mostly misplaced in Scala, since operators translate straightforwardly into methods, so it's always obvious where to look for the definition;
• and in any case I still like /: and :\ for folds.

In a prior post on livejournal, I described a problem and partial solution to using Hibernate with Scala. When I left things, I said:

The only real downside to this is that it doesn't enforce that entities are used only in the context in which they were created. I'd love to find a way to solve this. I think it might be possible to recover this by parameterizing the entity types, binding the type parameter with a single unsafe-but-safe cast as they come out of the database, and then enforcing that the implicit Context parameter matches the type parameter. I'll have to experiment with this, although truth be told, I'm not sure this level of safety is worth the hassle.

So I've done this experiment.