learning Scalaz: day 19


Added day 19 on the html5 book.

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.

sequencing tasks with sbt-sequential


In this post, I will discuss the execution semantics and task sequencing in sbt 0.13. First we will cover the background, and then I will introduce a new experimental plugin sbt-sequential that adds sequential tasks.


Mark said:

The sbt model is to have your side effects be local to your task so that as long as dependencies are satisfied, the task can be executed whenever. The win is parallel by default and enabling faster builds in practice.

In other words, with sbt, the build definitions only define the dependencies between the tasks. The timing at which these tasks are triggered is automatically calculated by sbt. To understand this, we should first look at the execution semantics of a Scala code with side effects.

traveling through the 4th dimension with sbt 0.13


Warning: This is a memo about sbt for intermediate users.

setting system

At the heart of sbt 0.13 is the setting system, just like sbt 0.12. Let's look at Settings.scala:

trait Init[Scope] {
  final case class ScopedKey[T](
    scope: Scope,
    key: AttributeKey[T]) extends KeyedInitialize[T] {
  sealed trait Initialize[T] {
    def dependencies: Seq[ScopedKey[_]]
    def evaluate(map: Settings[Scope]): T
  sealed class Setting[T] private[Init](
    val key: ScopedKey[T], 
    val init: Initialize[T], 
    val pos: SourcePosition) extends SettingsDefinition {

If we ignore pos for now, a setting of T consists of the lhs key whose type is ScopedKey[T], and the rhs init whose type is Initialize[T].

tetrix in Scala, an html5 book

I rebuilt tetrix in Scala series that I wrote last year into an html5 book using @n8han's Pamflet. I went through the git history commit by commit and upgraded the libraries and toolset to the state of the art as of 2013. This means multi-project build.sbt using sbt 0.13.0, Scala 2.10.2, every specs2 specs interpolated, and Akka 2.2.1 loaded on Android using pfn/android-sdk-plugin 1.0.6.

In addition, an extra day 13 was added for debugging and tuning up tetrix on Android.

what is object-oriented programming?

How do you define oop?

purely object-oriented programming

Purely object-oriented programming is defined to be:

programming with objects.

What's an object?

It is an atom that can hold references to other objects, receive predefined list of messages, and send messages to other objects and itself; and nothing else. A message consists of a name and a list of reference to objects.

This is it. The wording is mine, but the idea is from Alan Kay (2003), the guy who coined the term object-oriented programming. Anything else is either not directly tied to oop or an implementation detail.

sbt-logo proposal


.sbt build definition

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 scala-tools.org. 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