Evaluation Strategy and Laziness

Coming from Java I guess I'm used to "simple" strict evaluation

Scala allows for three kinds of evaluation

1. List.range(a, b) - strict evaluation
2. Stream.range(a, b) - lazy evaluation, evaluated once and cached
3. (a to b) - lazy evaluation, evaluated each time it is used

Call by name parameter

def someMethod(test:Boolean, findMe:String,  expensiveSearch:String ) = {

if(test)

  true

else

 expensiveSearch contains findMe

}

Instead of the type String for expensiveSearch use => String or () => String

You can choose which is most appropriate for your situation.

[2] Refers to a Haskell example which demonstrated that you have to turn your program quite a bit upside down to get real benefit from laziness. Is it worth?

[1]http://dcsobral.blogspot.com/2009/05/scalas-projections.html
[2]http://debasishg.blogspot.com/2009/03/learning-haskell-laziness-makes-you.html

Practically Functional

A very nice read up by Daniel Spiewak[1].
Scala combines OOP and FP. But how to use FP in practice? Practically Functional gives a fine introduction starting with the following "functional trademarks":

• referential transparency
• higher order functions
• closures
• immutability

Which then are described as "functional idioms" using a classification that looks like this:
Recursion -> HOF -> Combinators -> Monads
where each Level raises the level of abstraction.

Recursion
If functional programming does not allow loops then how do you do something repeatedly? The answer  is via recursion. To assist the programmer with that Scala offers nested methods.


Higher Order Functions
HOF are functions which take functions as their arguments. Some examples are:

• foldLeft, foldRight ( catamorphism)
• map ( "mapping" over a collection)
• flatMap ( "map" and afterwards "flatten")

Combinators
There are three kinds of Combinators:

• Sequential ( first a, then b)
• Disjoint (either a or b)
• Literal(exactly foo)

Monads

Properties:

• Typ constructor
• Single argument constructor
• flatMap / >>= (bind)

It is really nice to see such eye opening examples which really help you to understand code better and still do the job:

def readPeople(files: List[String]): List[Person] = {
  for {
    file <-files
    props <-readFile(file)
    firstName <-props get"name.first"
    lastName <- props get "name.last"
    ageString <- props get "age"
    age <- toInt(ageString)
  } yield new Person(firstName, lastName, age)
}


[1] pdf file

Ioke

Programming language, that seems like a abstract term because in most cases programmers just use it as a tool in their job. What motivations could be reason for creating a programming language.
Today I watched[1] Ola Bini talking about his creation Ioke. He discusses several properties of Ioke among them how close Ioke normal syntax is to its AST representation or Homoiconicity[2]

[1]http://blip.tv/file/2229441
[2]http://en.wikipedia.org/wiki/Homoiconicity