stricter Scala with -Yno-lub


For a flexible language like Scala, it's useful to think of subset of the programming language, like your own personal Good Parts, and opinionated style guides.


To try -Yno-lub, you can drop in the following sbt plugin to project/ynolub.sbt:

addSbtPlugin("com.eed3si9n" % "sbt-ynolub" % "0.2.0")


When Scala's type inferencer finds type A and type B to unify, it tries to calculate the lub (least upper bounds) of two types with regards to <:<. This process is sometimes called lubbing. Here are some of the examples:

scala> if (true) Some(1) else None
res0: Option[Int] = Some(1)
scala> if (true) List(1) else Nil
res1: List[Int] = List(1)

One idea I've been thinking about for a few years is that lubbing in its current form is not helpful.

herding cats: day 1


Check out my new series herding cats. (I'm writing it using Pamflet from the get go)

This is a log of me going through Cats, a functional programming library for Scala that is currently experimental and under active development.

switching Java version


I've been switching between Mac and Ubuntu, and between Java 6 and 7 lately.
This is a memo of how to switch Java versions on both Mac and Ubuntu.

Update: Yoshida-san told me about this thing called jEnv, which does all this.


Here's one way of loading different shell files depending on the OS:

## basic
[ -f $HOME/dotfiles/zshrc.basic ] && source $HOME/dotfiles/zshrc.basic

## aliases
[ -f $HOME/dotfiles/zshrc.alias ] && source $HOME/dotfiles/zshrc.alias

case "${OSTYPE}" in
# MacOSX

towards universal access at a conference


Two days of #ScalaMatsuri ended as a huge success. But for the next year, I'm leaving ourselves a few homeworks to work on. As the title suggests, the next goal that we should aim for is universal access. In Scala language, universal access principle indicates the fact that both methods and fields can be accessed interchangeably from outside.

For a conference, I mean universal access to mean being more inclusive to various groups of people:

  • women/men/straight/LGBT programmers
  • Japanese/English speakers
  • beginners and experts
  • postdocs
  • people from other Asian countries

ScalaMatsuri day1


This year was the second Scala conference in Japan. We've changed the name to ScalaMatsuri, which means Scala festival in Japanese. 300 tickets sold out. With invited guests and free tickets for sponsors, there may have been even more people. The venue was at CyberAgent, which runs blog service and online ad services.

scripting with Scala


The need for regular expressions is real. Whenver I need to transform a set of text files it usually ends up with fumbling through the documentation of find command, zsh, and StackOverflow Perl questions. I would rather use Scala instead of muddling through Perl. It's really the matter of my familiarity than anything else.

For example, I now have over a hundred reStructuredText files that I want to convert into markdown. I first tried pandoc, and it looked mostly ok. As I was going through the details, however, I noticed that many of the code literals were not converting over as formatted. This is because they were formatted using either single ticks or using Interpreted Text. Preprocessing the text with a series of regex replacements should work.

constraining class linearization (mixin order) in Scala


Woke up early yesterday, so I started skimming @xuwei_k's override blog post. The topic was so intriguing, I got out of the bed and started translating it as the curious case of putting override modifier when overriding an abstract method in Scala. In there he describes the conundrum of providing the default instances to typeclasses by using Scalaz codebase as an example.

Here's a simplified representation of the problem:

trait Functor {
  def map: String
trait Traverse extends Functor {
  override def map: String = "meh"
sealed trait OneOrFunctor extends Functor {
  override def map: String = "better"
sealed trait OneOrTraverse extends OneOrFunctor with Traverse {
object OneOr {
  def OneOrFunctor: Functor = new OneOrFunctor {}
  def OneOrTraverse: Traverse = new OneOrTraverse {}

curious case of putting override modifier when overriding an abstract method in Scala


This is a translation of Scalaで抽象メソッドをoverrideする際にoverride修飾子を付けるべきかどうかの是非 by Kenji Yoshida (@xuwei_k), a Scalaz committer.

First, a quote from Programming in Scala, 2nd ed. p. 192:

Scala requires [override] modifier for all members that override a concrete member in a parent class. The modifier is optional if a member implements an abstract member with the same name.

In this post, we'll discuss this "The modififier is optional." Since overriding an existing method with implementation requires override modifier, and failure to do so would result to a compiler error, there's not much to talk about for that case. We'll focus on whether one should put override modifier or not in the case of overring an abtract method. I don't think there's going to be any difference in Scala version, but let's assume the latest stable 2.10.3.

Scala: the flying sandwich parts


JavaScript existed since 1995 long before 'JavaScript: The Good Parts' (2008), jQuery (2006), and V8 (2008) happened. The interesting thing about Douglas Crockford's 'The Good Parts' is that unlike the other additive work, it's a book about subtracting features from the language.

I've been thinking about exploring a subset of Scala in a wonderland setting without the "real world" constraints such as Java familiarity and interoperability. If using Scala as an alternative Java is acceptable, why not try using it as an alternative functional programming language? Another point of this thought experiment is to see some of the duplicate constructs can be reduced. In this article, I'm not interested in finding out the idiomatic way, or calling something good or bad. I'm calling this The Flying Sandwich Parts (TFSP).

scopt 3.0


scopt is a little command line options parsing library.

Today, I'm releasing scopt 3.0. If you're not interested in the implementation details, skip to the readme.

Around March 4th, 2010, I became a committer to scopt, a fork of Aaron Harnly's scala-options that was written in 2008. I think I wanted to make a few changes around the usage text, key=value options, and argument list. Since then I've been fielding all the bug reports, including the request to publish the jar on On March 18, 2012, I forked the project again to scopt/scopt and released scopt 2.0.0 that added immutable parser.

After years of adding features on top of the other, I decided to rewrite scopt3 from scratch. The tipping point was Leif Wickland asking if there's a "philosophical reason that scopt doesn't have an intArg().".

Syndicate content