In the last few days, we implemented tetrix from the ground up. In the beginning I mentioned that I use this game to explore new ways of thinking. Since I had already implemented tetrix once in Scala, Scala alone really isn't anything new for me. The actual topic I wanted to think about using tetrix is the handling of concurrency.

Today's goal is to finish up the basic feature of Tetrix so it's playable.

REPL

A few people in the community is coming up with best practices in Scala.

We have a failing test from yesterday, which is a cool way to end a day for a hobby project.

[info] Moving to the left the current piece should
[info] + change the blocks in the view,
[error] x as long as it doesn't hit the wall
[error]    '(0,0), (-1,17), (0,17), (1,17), (0,18)' doesn't contain in order '(0,0), (0,17), (1,17), (2,17), (1,18)' (StageSpec.scala:8)

Yesterday, we approximated the game state using String. Let's see how we can improve this.

modeling the game

On screen there should be a 10x20 grid. I only want the current piece to be rendered in different color. We'll deal with the next piece window later. The different kinds of pieces can be represented using case objects:

sealed trait PieceKind
case object IKind extends PieceKind
case object JKind extends PieceKind
case object LKind extends PieceKind
case object OKind extends PieceKind

Every now and then I get an urge to explore a new platform, new ways of thinking, even a new programming language. The first thing I try to implement is always the same: a clone of the famous falling block game. I've implemented them in I think eight languages, Palm V that I borrowed, and on Android. Probably the first Scala program I wrote was Tetrix too. Some had network capability so two players could play against each other, and C# one had AI that kept playing on its own.

This is a memo of C# Linq features for Scala programmers. Or vice versa.

Type inference

C# has type inference. I try to use var when I can for local variables.

var x = 1;

Scala also has var, but the preferred way is to use immutable val if possible.

val x = 1

Creating a new List or an Array

C# can create collections in-line.

using System.Collections.Generic;

Unlike XML-based build tools sbt's build definitions are written in Scala (for both .sbt and .scala). This means that once one gets over the hurdle of learning sbt's concepts and operators, it doesn't take much for build users to start writing sbt plugins.

I've ported a few from sbt 0.7 before, but I've also been writing some original ones recently that I'd like to share.

treehugger.scala is a library to write Scala source code programmatically. It's also an implementation of Scala AST based on Reflection API, now available from github eed3si9n/treehugger.

Edit:
I've expanded this into a complete guide using awesome n8han/pamflet.

• See treehugger.scala's pamflet

Scala the language is one of the most elegant, expressive, consistent, and pragmatic languages. From pattern matching to the uniform access principle, it got so many things right. And Scala the ecosystem and Scala the community only makes it better.

In Scala 2.9.1, locally declared implicits are preferred over imported ones. The problem is that the spec does not cover such behavior. My original hypothesis was that either I did not understand the spec correctly, or the spec was wrong. Based on the assumptions, I set out to explore the implicits resolution precedence last week. Like MythBusters say, the best kind of result is when you get something totally unexpected. It turns out that both of the hypotheses were wrong.

My understanding of the relevant part of the spec was correct, and spec was correct as well. According to SI-5354, what's wrong was the compiler implementation: