Go to content Go to navigation Go to search

Scala: first steps
Saturday August 18, 2007 by Derek Young

I’ve started learning Scala – it’s one of the most exciting languages I’ve come across in a while. I’ve seen Scala described as “a Java like language” which I think really sells it short. It feels to me more like a functional language like OCaml and Haskell that happens to target the Java virtual machine.

Scala mixes functional and object oriented features, provides threadless actor based concurrency (Erlang style), plus allows direct access to all libraries available to Java, a huge benefit.

Some Scala of the features I really like from its functional influence:

  • type inference
  • destructuring/pattern matching with the match keyword (something more languages should adopt)
  • selective lazy evaluation
  • curried functions
  • “case classes” (variants types in OCaml)
  • parameterized types (like generics in Java)

Scala’s syntax

The syntax of Scala feels very natural with a strong C/Java/C++ style. It also blends in syntax features common to functional languages, like allowing function definitions with a single statement to omit braces. Function calls are written with parens holding the arguments, separated by commas, which is much easier than the terse but awkward style of OCaml, where arguments are separated only by whitespace.

I do miss a special / / syntax for regular expressions. Scala does have a special syntax to embed XML directly in code, so why not allow the same for regular expressions? I like how Groovy does this. Literals quoted with / / are strings, not any type of regular expression object. It’s the context of the string that decides if it’s treated like a regexp or not.

Scala type inference

While parameters and expression can have type annotations in OCaml, they are not required. The compiler can infer types globally with no type annotations. While this keeps the code terse it causes a few problems. First, type errors are difficult to understand and fix. Because all methods are interrelated the error could be in a caller of a method, the method itself, or both. Second, when looking back at a code you’ve written long ago the type information can be hard to decipher (tools that use type information reported from the compiler can help). Finally, to provide enough information for the compiler to infer all types, the rules of OCaml are very strict – no implicit type conversions (even obvious conversions like int to float), and different operators for integer and floating point math (+ for int and +. for float).

Unlike OCaml, Scala requires you to specify the type of your method parameters and return type (although not for all cases of anonymous functions). This makes the code more understandable in most cases, at the expense of being more verbose. The standard operators (+, -, /, *) are used for numeric expressions and implicit conversions are supported.

identity

To get a feel for Scala’s type inference features I started with the most basic function of all, a function that returns its argument—the identity function.

In OCaml:

let identity x = x

In Scala the parameters have to be fully typed, but what is the type of x? It can be any type, which we’ll call A:

def identity[A](x : A) : A = x

If you were to fully specify the type in OCaml, it would read:

let identity (x : 'a) : 'a = x

The fully specified version is very close to the Scala version.

addOne

What about a function that adds one to its argument for all numeric types? Although it seems like it would be easy to write there is no straighforward way to write this function in either OCaml or Scala. In OCaml, + operates only on ints, so using it in a function prevents it from working on any other numeric type. In Scala, all numeric types derive from class AnyVal, but so does Boolean and Unit (like void). There is no class defining “all objects that can have one added to them”.

Dynamic languages make this type of problem easy. You define a function that applies + to its argument and that binding is resolved at runtime.

Next steps

I plan on writing some more substantial Scala code, bigger than the identity function :) I do wonder what the future roadmap looks like for Scala—will it be actively developed? Or is it just an academic experiment? How big is the community of users? And is it growing?

  1. If you need avoid escaping in regular expressions, then
    you can write:

    “”“\d+”“”

    instead of

    “\\d+”

    See 1.3.5 in “The Scala Language
    Specification”


    — Akcelisto    Apr 3, 05:12 PM    #
  Textile Help