My Scala Days [Week 2] and [Week 3] Condensed

Most of the materials here are excerpts from vaious resources that I have come across online as well as from ebooks. Some of the sentences are described as they are. I will try to keep all the references but please excuse me if I have missed some soruces.

I realized that I have come up with a soup of random excerpts. I will try to clean this mess up

On Auxillary Constructors #

Every constructor invocation in Scala will end up eventually calling the primary constructor of the class. The primary constructor is thus the single point of entry of a class.

More Learning Resources #

The Neophyte’s Guide to Scala is a pretty good one to start looking into not-so-beginner-level text

Good things to take from it as far as I have learnt:

• Extractors are the reason pattern matching works in Scala
• Extractors has the opposite role of a constructor
• Constructors create an object from a give list of parameters, an extractor extracts the parameters from which an object passed to it was create

I started reading Scala by example. It is such a great companion for Odersky’s course on Coursera.

If you are doing Coursera, I suggest you do each lesson twice. Things get clearer on the second time.

One thing that I got to know is that I cannot make sbt to work with Java8 for sbt. It sucks and well I have to change back to Java7. The way to do is:

java -version
export JAVA_HOME=$(/usr/libexec/java_home -v 1.7)
java -version

One thing to learn case classes is to do Case Class by Example

The greatest compilation of Scala libraries. Awesome Scala

The best thing that I did during this week was filling up blanks in Scala Exercises. You will get it when you see it. It is pretty cool to learn in this way.

I have to revisit Scala Exercises for:

• Maps and sets
  • Remove elements with - for tuple like removal
  • Remove elements with – for List like removal
  • Sets and maps are independent of order
  • Super weird case for sets
  • Note that very small Sets (containing up to 4 elements) are implemented differently to larger Sets; as a result, their iterators produce the elements in the order that they were originally added. This causes the surprising (and arguably incorrect) behaviour that we can see in the following example.

val xs1 = Set(3, 2, 1, 4, 5, 6, 7)
val ys1 = Set(7, 2, 1, 4, 5, 6, 3)
(xs1 sameElements ys1) //true

val xs1 = Set(1, 2, 3)
val ys1 = Set(3, 2, 1)
(xs1 sameElements ys1) //false

• String format

val s = 90
"%d days left to be awesome" format s-10 // "80 days left to be awesome"
"%d days left to be %s" format(s, "hoola") // "80 days left to be hoola"

• variable shadowing with backquote `

def patternEquals(i: Int, j: Int) = j match {
  case `i` => true
  case _ => false
}
patternEquals(3, 3) should be()
patternEquals(7, 9) should be()
patternEquals(9, 9) should be()

• Infix types
• Stream is a lazy list

I have to look into Scalania

This tutorial explains Akka in very simple terms and give good examples where you can learn a lot.
Concurrency and Fault Tolerance Made Easy: An Akka Tutorial with Examples

This shows a way to write a simple chat server with actors
This

While I am doing Scala Exercives, I realize that I have to learn more about:
Learn more about

• Case Classes
• Implicits

One take for me for this week is that I have to be aware of the fact that vals and vars and ruin can ruin my day. I was so much into functional programming and immutables states that I even make val to variables that I have to mutate.

• Iterables
• Traversables
• Sets
  • A collection of unordered, unique values
• Streams
  • A lazy list where elements are evaluated as they are needed
• Lists
  • Elements of lists have the same type
  • Immutable
  • Lists represent a linked list
• Arrays
• Seq

Implicit Conversions #

If you have defined Rational class and then you implemented some overloaded methods for additions and subtractions with Rationals and Integerss, you can make something like: (provided that you have a auxillary constructor which passes the denominator as 1 when there is just a numerator when the object is instantiated)

def +(that: Rational):Rational =
new Rational(this.numer * that.denom + this.denom * that.numer, this.denom * that. numer)
def +(that: Int):Rational =
this + new Rational(that)

val a = new Rational(3, 8)
a + 2 //You will get a Raional as a result

But you can’t do this 2 + a. Since it is a method call on the number 2, which is an Integer. But the Int class contains no multiplicatoin method which takes a Rational argument.

implicit def intToRational(x: Int) = new Rational(x)

Now you can do 2 * a.

Control Structures #

if-else expression in a more functional style:

val filename =
  if (!args.isEmpty)
  args(0)
else
  "default.txt"

I might have already said this before or you might have heard enough of this but I have to emphasize on the importance of using vals over vars.

Advanatages are:

• More functional style
  • Tells you that variable will never change
• Support equational reasoning

Exercises #

Here are some exercises that I want you guys to try out:

Provided that you have

val tokens = List("The", "Program", "Halted")
val tags = List("DT", "NN", "VB")

Make a String which is:
“The/DT Program/NN Halted/VB”

On Type inference #

Why can’t Scala infer the method argument types?

The type inference algorithm does local type inference, which means it doesn’t work globally overy the whole program, but locally within certain scopes. Here, it can'te tell what types the arguments must have, but it is able to infer the type of the method’s returned value in most cases, because it see the whole function body. Recursive functions are one exception where the execution scope extends beyond the scope of the body, so the return type must be declared.