de.velopmind | The Det about Programming

February 11, 2013

Functors in images

Filed under: FunctionalProgramming, Scala — Tags: , , — de.velopmind @ 2:40 pm

During the long break between my posts in the end of last year I pondered how a visual representation for all that Functor, Monad, Applicative stuff would look like. I myself are a visual thinker, i.e. thinking always involves images moving and rotating through my head. Visual representation now helps to get an imagination of concepts and make thinks more clear, at least to me.

Now, this is the first post where I try to present a visual representation. Fiddling with images on a computer now is not my kind of art, and time is scarce. But I didn’t want to wait longer to present a first result, so bare with some lack of aesthetics in the pictures.

This post is about Functors, or more precisely the map method, and is especially related to my post: Functors, Monads, Applicatives – different implementations . It is therefore recommended that you (re)read that one, and best its predecessor,  before. (I thought about changing those posts to include the images, but decided against it).

Now, it all starts with an instance of class MyBox[A] and a function from A to B, in this case a MyBox[String] and a function String=>Int :

FunctorsInGraphics-1

As we have seen in the post referenced above, map can be implemented as a standalone function or as a method on class MyBox. We will begin with the latter. Let us now turn the MyBox image slightly in our direction:

FunctorsInGraphics-2

We now have this MyBox thing and the function. Let us now think about the function to be some sort of pipe that can take a string on one end and outputs an integer on the other end. Calling the map method/function is now comparable to plumbing the pipe to the MyBox thing:

FunctorsInGraphics-3

Ok, here we “put the pipe on it”. Beneath the picture you see three different ways to implement map, and the first one in black is the one this image is about .

When we now let the plumbing do its work due to the map method, it not only gives the result value of the mapped method, but this value is wrapped in a MyBox again.

So this is the complete picture of this scene:

FunctorsInGraphics-4

This is very easily grokkable, and holds for may cases where map is implemented as a method on a class. For example for Option, or for collections:

FunctorsInGraphics-8

Here is how it is applied maybe to a List. The original box has many values, and the plumbing puts each into the pipe and produces a similar box with the output values.

That was easy and matches mostly the first experiences we make with map in Scala. But the original notion presented in the first post was more according to this:

FunctorsInGraphics-6

Map is here thought as being a function that converts (lifts) a function from A to B into a function from M[A] to M[B]. Fed with a function String=>Int, it produces a function  MyBox[String]=>MyBox[Int]. And this “lifting”, presented in the right way, seems more in the line of thinking of category theorists.

FunctorsInGraphics-7-2

We now have  a world with some values of some types on the left, together with functions between those types. In the picture the types are String (value “hello”) and Int (value 5), and the function is what you see in the red box. In this imagination we consider the function map now being a pipe, in fact one which moves the function from the left side world to the right side world, where any value is hidden in a box of some type (here: MyBox). And as surely as the original function could work with “hello” and produce the 5, the transfered function can handle a “hello” in a MyBox and produce a MyBox with a 5 in it.

Hopefully you found this representation of map with images as useful as I did. I try to use this way of representation in further posts, perhaps even inline in the “Functors, Monads, Applicative” series.

January 21, 2013

Functors, Monads, Applicatives – taking Monad apart

Filed under: FunctionalProgramming, Scala — de.velopmind @ 1:22 am

Welcome to a new (and long overdue) article in the series around Functors, Monads and Applicatives.

As promised in the last article, we will have now a closer look at Monads.  I think it would be good if you read the last post again.

We talked about the two type variables A and B that form the signature of the function given to map, A=>B. We detected, that B stands for any type, even if it is as complex as List[String], or even MyBox[Char]. As an example we mapped a function of type String=>MyBox[Char] to a MyBox[String], and the result was a MyBox[MyBox[String]. But we detected also that there already is another function, flatMap, that already takes the more specific signature A=>C[B], or here: A=>MyBox[B]. So we concluded:

It seems that flatMap is only a special case of the more general map.

Let us reconsider:

(A=>B) => (C[A] => C[B])

map takes a function A=>B, and converts it to a function taking a MyBox[A] and resulting in a MyBox[B]

if we give map a function A=>MyBox[T], applying that to a Mybox[A] results in a nested MyBox[MyBox[T]] .

flatMap is more specific and takes only functions of type A=>MyBox[T], and results only in a MyBox[T].

This is crucial: The result of flatMap is a flat Container, not a nested one!

So let us look at how this function flatMap may be implemented. We already presented an implementation in the first article:

def flatMap[A,B]( func:A=>MyBox[B] ): MyBox[A]=>MyBox[B] = (a:MyBox[A]) => func( a.value )

Well, if you compare that to the implementation of map some lines before that, the difference is simple: flatMap calls func(a.value) and does nothing but returning the result of func, while map wraps this result into a new MyBox .

If we would compare the object id of the func result with the object id of the flatMap result, we would see: It is identical. It is exactly the result of func that is returned.

We also had a different implementation in the second article (I change the type variables here, and method to function, to harmonise with the code above) :

def flatMap[A,B](func:A=>MyBox[B]) = (a:MyBox[A]) => map(func)(a).value

This implementation routes the given function of type A=>MyBox[B] to the map function, which -as we already know- results in a nested MyBox[MyBox[B]]. Then the value method on this result is called, which results in exactly the wrapped MyBox[B] instance. The effect is similar as above: if we would inspect the object id of the result of func and the object id of the overall flatMap result, it would be the exact same object.

Now let’s do something funny: Let’s reduce flatMap to the application of map, and let us abstract the subsequent unwrapping into a new function:

def flatMap[A,B](func:A=>MyBox[B]) = (a:MyBox[A]) => flatten(map(func)(a))
def flatten[B](m:MyBox[MyBox[B]]):MyBox[B] = m.value

Voilá, the new function is called flatten, and if we look at the implementation of flatMap, it becomes obvious why it is named so in Scala:

It is the combined effect of map and flatten.

It is interesting that -although flatMap has such an important meaning for Monads, e.g. in for-comprehensions- it is often this flatten function that is considered the specific property of Monads, and flatMap is only considered a convenience function (see: “Scala in Depth” – J.Suereth, Ch. 11.2.1).  (For more on that, read this paragraph in the Wikipedia article about Monad). But keep in mind that the important part for programming in Scala (e.g. the for-comprehension) is the flatMap method.

Well, by now we haven’t gained much. The result of some flatMap(somefunc) applied to an MyBox[A] is a MyBox[B] that comes directly from somefunc, and the MyBox wrapping the A is forgotten. Why not, it wouldn’t change anything, would it?   Same for Option:  A Some(Some(“hello”) would become a Some(“hello”), a Some(Nothing) would become that Nothing. Wouldn’t it?

So let’s now broaden the view somewhat:

Let’s start with the List class. Assumed we have a list val mylist =  List(1,2,3) and we call map( x => List(x, x*x, x*x*x)) on it, it would result in

List[List[Int]] = List(List(1, 1, 1), List(2, 4, 8), List(3, 9, 27))

Now, if we would have to implement the flatten method on List now, so that the result is

List[Int] = List(1, 1, 1, 2, 4, 8, 3, 9, 27)

How would we do that? Well, our flatten method would have to look somehow like this:

def flatten(xs:List[List[Int]]) =
    xs.foldLeft(List[Int]()) ((res,item) => res ::: item)

We take our list of lists and call foldLeft on it with a startvalue of an empty result list. Then each item in the list of lists (i.e. each List[Int]) is concatenated to the actual result. (You should be familiar with the functionality of foldLeft. If not, look it up now).

The thing here is: The result is a totally new list, built as a concatenation of the many lists contained in the map result. So it made sense to extract the flatten function.

But there’s even more to it:  MyBox, Option, List have all in common, that they are about holding values and nothing more. They are mainly containers.

Now let’s enhance our MyBox implementation, and rename it on the fly:

class LogBox[T](val value:T, val mesg:String="")

Our new class has an additional attribute mesg of type string which defaults to the empty string. Thus we can still create an instance by only providing a value, but we can also put some additional log message in:

class LogBox[T](val value:T, val mesg:String="")
val boxedint1:LogBox[Int] = new LogBox(1)       // --> boxedint =  LogBox(1, "")
val boxedint2:LogBox[Int] = new LogBox(2,"two") // --> boxedint =  LogBox(2, "two")
val boxedint3:LogBox[Int] = new LogBox(2,"three") // --> boxedint =  LogBox(2, "two")

So far, the interesting part comes when we implement map and flatten (and surely flatMap) on this new class, to use it in monadic style.
Let’s start with map and an example of its function:

class LogBox[T](val value:T, val mesg:String="") {
    def map[B](f:T=>B) = new LogBox(f(value), mesg)
}

val test = new LogBox(2, "hello")
val result = test.map( v => v*2 )

result.mesg  // --> "hello"

What is notable here: The map method creates as its result a new LogBox with the value being the result of the application of f. This is known. But this new LogBox also gets the mesg value of the current instance, thus carrying the mesg forward. If we call .mesg on the result, it is the same as we had in the former LogBox.

Not let us implement flatMap and flatten:

class LogBox[T](val value:T, val mesg:String="") {
    def map[B](f:T=>B) = new LogBox(f(value), mesg)
    def flatMap[B](f:T=>LogBox[B]) = flatten( map(f) )
    def flatten[B](m:LogBox[LogBox[B]]) = new LogBox( m.value.value, m.mesg+m.value.mesg+"\n")
}

flatMap  is as we would expect it to be, only now implemented as a method: it is flatten after map with the given f .

The flatten itself is now the interesting part.  Let us assume, that the current instance of LogBox looks like this: LogBox(7, “hello”).

Let us further assume that the function f calculates its argument times 6 and so returns a LogBox like this: LogBox(42, “world”).

Then what map would return would be:    LogBox(   LogBox(42, “world”),   “hello” ) .

That is: The outer LogBox contains as value the inner LogBox which is the result of applying function f to the former value. And the outer LogBox contains as mesg its former content, as this is kept by map and carried forward.

flatten now constructs a new LogBox whose value is the value of the inner LogBox, as that is the calculation result. The new mesg on the other hand is a concatenation of the outher mesg and the inner mesg, extended by a newline:  “helloworld\n”.

At the end of this post let us see that in action, based on a start value on which some calculations are done and logged:

val one = new LogBox(1)

val two = one.flatMap( x => new LogBox( x+1, "plus one"))

val four = two.flatMap( x => new LogBox( x*2, "times two"))

four.value  // --> 4

four.mesg   // --> "plus one
                    times two
                   "

So far for now. I can’t tell what will be the topic of the next post, so I avoid any promises. This last paragraph will be replaced once a new post becomes available.

May 20, 2012

Functors, Monads, Applicatives – playing with map (Functor)

Filed under: FunctionalProgramming, Scala — de.velopmind @ 5:37 pm

The first blog post about Functors and co.  introduced the three basic function transformations that form Functor, Monad and Applicative.

a) ( A=>B ) => ( C[A]=>C[B] ) | Functor
b) ( A=>C[B] ) => ( C[A]=>C[B] ) | Monad
c) ( C[A=>B] ) => ( C[A]=>C[B] ) | Applicative

In the last post in this series I used the map function as a demonstration for different styles to implement the three concepts. Let’s now stay a bit longer with our Functor, play a bit with map and look what we detect.

Although these patterns are not metaphors, I will neverless begin to think a little bit metaphorically about a Functor – or more precisely: about our MyBox.

In the examples so far we have seen the class MyBox as a carrier of a value:

class MyBox[T](val value:T)

And we have also seen implementations like the following:

def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )

or even

n.map( (a:String)=>a.length ).value // -> 5

Notice here the access to the box’s value with a.value . While the first example, map, encapsulates this access in its implementation, it is done in the open in the last example.

But an important fact about Functors et al is exactly this: The value is hidden inside the Functor wrapper, and access to it is only possible by passing a function to some sort of “guardian” (map, flatMap). This “guardian” has the control over the Functor, and he “grants” the access to the value to the “visitor”, i.e. the given function.

It is as if the value will never get out of the Functor, but stay inside. So, if you want to cause any effect on it, you have to pass a transformation into the functor. The result of the effect stays in the Functor.

Another metaphor is to think of a Functor wrapper as a test tube. You have some dark blue liquid in it. Then you open the tube and give some reagent into it, and after a short while the dark blue liquid is transformed into a light green sort of sirup. All that happened inside the test tube.

So now we have our MyBox, containing a string value, and we open the lid, throw a function into it, and now the value and the function react, resulting in an integer value inside that MyBox.

Ahem, ok, so far for the metaphors. The thing is, that our MyBox is a nice wrapper for demonstration, but it is absolutely useless. There is no reason to keep the value inside, and no reason why we shouldn’t do something like this:

val boxedstring = new MyBox("Hello")
val hellolenght = boxedstring.value.length

But let’s assume that instead of this boring MyBox the wrapper would be more interesting. It could be a collection, like List. Then applying the function to every element and collect the results in another List would be a tedious task. We would have to externally iterate over the elements. The map function does this for us internally. Or consider the Option class. It is very much like our MyBox, but it has some kind of semantics. And transforming the value via map plus a given function keeps this semantic. That is, when used seriously, a Functor is not such a dull thing like MyBox, but provides some interesting information or functionality. It is a context around the value.

Ok, I digressed a bit, so let us come back to map:  ( A=>B ) => ( C[A]=>C[B] ) 

The map function allows us to access the value inside a wrapper C[_], in our case MyBox, and allows us to transform not only the value itself, but also the type of the value. We saw that in our example, where the string value “Hello” in the MyBox was transformed into an int value representing the length.

If one starts to work with generics and type parameters, one can easily be confused by the meaning of a type parameter like A or B. These two letters each simply stand for a “type”, but there is no statement about what this type is. It can be a simple type, like String or Int in our example, but it can also be a complex generic type.

For example, the result type B could be a List[String]:

val boxedstring = new MyBox("Hello")
val splitter = (a:String) => a.split("").toList
map(splitter)( boxedstring ) // Result: MyBox[List[java.lang.String]]

Splitter is a function of type String=>List[String], and according to how map works, the overall result is of type MyBox[List[String]]. You can imagine that this works for many other types too, like e.g. Option, so given a function of type String=>Option[Int] we would get a MyBox[Option[Int]].

Now let’s do a funny thing:

val boxhead = (a:String) => new MyBox(a.head)
map(boxhead)( boxedstring ) // Result: MyBox[MyBox[Char]]

Wow, two things are interesting here:

  1. The result type is a MyBox containing a value of type MyBox[Char] – we have a box in a box!
  2. The function type of function boxhead is String=>MyBox[Char]

The general signature of map is (A=>B), in this case it is (String=>MyBox[Char]).

But we already have a function with the general signature A=>C[B], which in our case would be A=>MyBox[B]. That is the signature of flatMap !

It seems that flatMap is only a special case of the more general map. There is a relationship between Functor and Monad, and we will take a closer look to flatMap in the next article.

For now let’s try something else. Until now we have only worked with functions that take one parameter. But what happens if we have one value but a function that takes two?  That is where currying comes into play:  Each function taking two parameters and returning a result can also be expressed as a function taking one parameter and returning another function which takes the second parameter and then returns the result:

scala> val add = (a:Int, b:Int) => a + b  // function with two parameters returns result
add: (Int, Int) => Int = <function2>

scala> add(3,5)
res13: Int = 8

is equivalent to

scala> val add = (a:Int) => (b:Int) => a + b // function with one parameter returns function
add: Int => (Int => Int) = <function1>

scala> val add3 = add(3)    // new function based on argument 3
add3: Int => Int = <function1>

scala> add3(5)     // function returns result
res15: Int = 8

More generally: Every function taking more than one parameters can be expressed as a chain of functions taking one parameter and returning a function which also takes one parameter. That should not be new to you, as we used that technique in the last post to transform the map function from one implementation style to another.

Now back to map. As map takes a function with only one parameter, each function with more than one parameter has to be changed into its curried form.

An example:
A function with two parameters

val conc = (a:String, b:String) =>  a + b

is changed to its curried form.

val conc = (a:String) => (b:String) =>  a + b

Now let’s try what happens when we put that into our map for boxedstring.

map(conc)(boxedstring) // Result: MyBox[String => String]

Wow, and suddenly we have a function inside a box! It seems here we are at the fundaments of Applicative, as the result type is exactly the signature of the apply function.

We talked a bit about what a Functor wrapper like MyBox in practice can be, and we played a bit with the map function. Perhaps this encourages you to experiment more with it.

So far for now, and happy mapping. In the next post we will play a bit with flatMap.

May 4, 2012

Functors, Monads, Applicatives – different implementations

Filed under: FunctionalProgramming, Scala — de.velopmind @ 8:49 pm

In the previous blog post I claimed that Functors, Monads and Applicatives can be presented in an easily comprehensible way:

a) ( A=>B )      => ( C[A]=>C[B] )   | Functor
b) ( A=>C[B] ) => ( C[A]=>C[B] )   | Monad
c) ( C[A=>B] ) => ( C[A]=>C[B] )   | Applicative

Thus they are perceived  as transformations/conversions from some function type involving an A and a B to the type C[A]=>C[B] .

We then created a container MyBox, which can keep a value of some type, and some functions which implemented the above mentioned signatures.

For example the Functor transformation was implemented as a standalone function named map :

def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )

But what I want you to understand in this post, is that this –map as a function taking a function- is only one possible implementation, and that there are very different ways to structure the concept represented by the function map . This is much more true for Scala, which is a feature rich hybrid OO-FP language. To demonstrate this, let’s stay with Functors and the shown map function. What you see here will be applicable for the other concepts, Monad and Applicative, too.

First, let us again have a look at the signature of map:

( A=>B ) => ( MyBox[A]=>MyBox[B] )

According to this signature, map takes a function of type A=>B and returns a function which takes a MyBox[A].  In the end the result is of type MyBox[B]. The second pair of parens can easily be left out:

( A=>B ) => MyBox[A] => MyBox[B]

What we now see is a curried form that we can transform back into a multi-parameter function:

((A=>B), MyBox[A]) => MyBox[B]

We now have a function taking two parameters -a function A=>B and a MyBox[A]- and resulting in MyBox[B]. In such a case the order of the parameters isn’t really important, so we can change that easily to

( MyBox[A],(A=>B)) => MyBox[B]

what in curried form again is

MyBox[A] => (A=>B) => MyBox[B]

Let’s take our first implementation and adapt that according to this signature:

def map[A,B](a:MyBox[A]): (A=>B)=>MyBox[B] = (rawfunc:A=>B) => new MyBox( rawfunc(a.value) )

Now map first takes the container to work on and then returns a  function that is bound to that container, but  expects as parameter the bare typed function which shall be applied to produce the result.

This is a signature for map that you will also find in articles, either as a primary way to implement it, or as a helper function, delegating to  the other signature (like here).

So far the class MyBox and the function map are only loosely related, i.e. the function map can be located anywhere in our code base. To organize it better and document the relationship of map with MyBox, we could possibly declare it as a method on a companion object:

object MyBox {
 def map[A,B](a:MyBox[A]): (A=>B)=>MyBox[B] = (rawfunc:A=>B) => new MyBox( rawfunc(a.value) )
}

Much more, if we have a function that takes an instance of some class as its first parameter, this is only a functional way to describe a method, which in classical OO would belong to the class itself. So the signature

(MyBox[A],(A=>B)) => MyBox[B]

is a hint, that maybe map should be implemented like this:

class MyBox[A](val value:A) {
 def map[A,B](rawfunc:A=>B) = new MyBox( rawfunc(this.value) )
}

So now we can call map directly on an instance of MyBox:

val n = new MyBox("hello")
n.map( (a:String)=>a.length ).value // -> 5

This is a nice way to implement Functors and Monads in case you are the class’ author and have such features already in mind. As you may know, Scala’s for-comprehension is only syntactic sugar for calls to map and flatMap on instances. Therefore our class can be used inside such expressions too.
Another Scala-typical way to provide methods on objects although their class does not implement them are wrapper classes and implicit conversions. How this would look like for our MyBox, you see below, including also the Monad method flatMap.

class MyBox[T](val value:T) {
   override def toString() = "MyBox("+value+")"
}

class MyBoxWrapper[T](w:MyBox[T]) {
    def flatMap[R](f:T=>MyBox[R]) = map(f).value
    def map[R](f:T=>R) = new MyBox(f(w.value))
}

object TestMonadWrapper {
    implicit def myBoxToWrapper[S](mb:MyBox[S]) = new MyBoxWrapper[S](mb)

    def main(args:Array[String]) {
        val ma = new MyBox("hello world")
        println ( ma.map((a) => a.length) )

        val res = for {
                    a <- ma
                  } yield a.length + 2

        println(res)

        val mb = new MyBox("hola mundo")

        val res2 = for {
                     a <- ma
                     b <- mb
                   } yield a.size + b.size

        println (res2)
    }
}

This is an extended example, so let’s have a walk-through.  Class MyBox implements a toString Method to allow for convenient printing on console, so we don’t have to call .value to see what the value is. MyBox does not implement the methods map and flatMap itself, but we have a wrapper class MyBoxWrapper that implements them for us. Our application object TestMonadWrapper contains some tests in the main method, and an implicit conversion that wraps a MyBox instance into a MyBoxWrapper whereever the methods map and flatMap are called on a MyBox instance. This is the case for ma and mb inside the for-comprehensions.

Last but not least Scala also knows typeclasses -not as a language feature but as a pattern-, which are just another way to provide function implementations for specific types, a concept taken from Haskell. I don’t want to dive into that matter here now. To see Monads implemented as a typeclass, have a look into Daniel Spiewak’s article Monads are not metaphors , where the concept Monad is shown as a trait, implemented by two implicit objects for different types, or at Eric Torreborre’s article The Essence of the Iterator Pattern, where he demonstrates Functor and Applicative as typeclasses right from the beginning.

In my examples you have so far always seen the functions named map, flatMap and apply. The first two match with how the Scala standard library is implemented and the for-comprehension works. But the name apply must be taken with care, as this is in Scala a conventional method to use object references like functions.

Indeed, other languages implement the concepts of Functor, Monad and Applicative too but use other names for the functions. Namely in Haskell, the source of those ideas, the methods are named differently and sometimes confusingly for a Scala developer. So is the method map named fmap there, not to be confused with Scala’s flatMap, which is named bind in Haskell. Beside that, Haskell uses even symbolic names for the functions.

Another blog post which I found recently and which presents Functors, Monads and Applicatives in a similar reduced way like my first post, is Functors, Applicative Functors, and Monads aren’t that scary. The author took the Haskell function names for Scala too.

All in all, the names are of no importance.  Much more, have a look at the signatures to recognise the patterns shown in the first post, even when they are mutated, like seen in this post.

In the next post we will play with map, discover the other two function signatures of the first post, and think about how it comes that we would need flatMap and apply.

April 28, 2012

Functors, Monads, Applicatives – can be so simple

Filed under: FunctionalProgramming, Scala — Tags: , , , , — de.velopmind @ 5:37 pm

When I started trying to get into these weird topics named “functors” and “monads” and so on, which came up in the Scala mailing list, I was more than slightly confused [1]. I read some articles (in the beginning not many existed), listened to mails, consulted book chapters, and even started learning Haskell to consult the very fine “Learning a Haskell for great good” chapters on that matters. Different authors use different ways to explain -and implement!- these concepts, what in the end is helpful. You can read an article, think, read some other perspective, come back to the first article again, a.s.o.

But it took some time to realise how darn simple it all can be in principle (and took more time to finally write about it). I worked with and restructured some examples until the simplicity of it all became obvious. So let me now present you my perspective on it, and perhaps it will help you to get into these seemingly strange things:

Given some type constructor C[_] and two types A and B, we want to apply functions of type C[A]=>C[B] .
Unfortunately we have only functions of types A=>B,  A=>C[B] and C[A=>B] at hand, so we need adequate transformations for them:

a) ( A=>B ) => ( C[A]=>C[B] )
b) ( A=>C[B] ) => ( C[A]=>C[B] )
c) ( C[A=>B] ) => ( C[A]=>C[B] )

All these are transformations of some given functions into the function type we need, and all these transformations even have names.

a) ( A=>B )      => ( C[A]=>C[B] )   | Functor
b) ( A=>C[B] ) => ( C[A]=>C[B] )   | Monad
c) ( C[A=>B] ) => ( C[A]=>C[B] )   | Applicative

That is the pattern we have to learn by heart and keep in mind. All other is simply applying that pattern, present it in different forms and implementations [2].

Too fast? Too abstract?
Ok, now that you surely have learned this scheme by heart and can reproduce it without spiking into this article, we’ll have a closer look at how and why that works.
It all starts with a container of some type C, which is able to hold one or more values of some type A. So we have C[A] to start with.
The container itself can serve different purposes. We will come back to that in a  follow-up post.
To keep things easy for now, let’s start with the most simple: A box.


class MyBox[T](val value:T)

Then we can put a value of some type into such a box, for example a string.


val boxedstring:MyBox[String] = new MyBox("Hello")

Now we want to apply some computation or transformation on the value (type A) in C, without leaving C. That means, the result value of some type B shall also be in a C. In other words: We want to apply functions of type C[A]=>C[B].

In our example: Let’s assume we want to compute the length of the string in MyBox, and get the result again in MyBox. This would need a function of type MyBox[String] => MyBox[Int], which would calculate the lenght but somehow stay inside the box:


def lengthOf( a:MyBox[String]) : MyBox[Int] = ....

The problem is that we already have some interesting computations -like the length of a string- at hand, but they are not of the correct type. They are of much more functions on the raw types A=>B, or functions of type A=>C[B] or even the raw functions already wrapped in C, resulting in C[A=>B] (Why that is, we talk about later).

In our example, we have a function:


def rawLengthOf(a:String) : Int = a.length

We can see, that we need to transform it. So let’s write a transformation for it:


def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )

Let’s look closer into it: map is a function that takes another function of the raw types A=>B as parameter and returns a new function that takes a MyBox[A], applies the raw function, and wraps the result in a MyBox again.

Now let us put all these things together:


class MyBox[T](val value:T)

def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )
 val boxedstring:MyBox[String] = new MyBox("Hello") // a boxed value

def rawLengthOf(a:String) : Int = a.length // the raw function we want to use

val transformedLenghtOf = map(rawLenghtOf) // applying the transformation, so we get our new function

val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function

So we have a MyBox[_], and we have a map function for MyBox. Congratulations, this is your first Functor!

The other two examples work similarly.

We start with our boxedstring again, but then we have:


def lengthOf(a:String) = new MyBox( a.length ) // a function which takes a raw type but boxes the result itself

Why such things can happen, we will see later.

So we need a new transformation:


def flatMap[A,B]( func:A=>MyBox[B] ): MyBox[A]=>MyBox[B] = (a:MyBox[A]) => func( a.value )

flatMap is a function that takes a semi-raw function of type A=>MyBox[B] -e.g. String=>MyBox[Int]-, and returns a new function that takes a MyBox[A], applies the semi-raw function and simply returns its result.

The rest now looks almost the same:


val transformedLenghtOf = flatMap(lenghtOf) // applying the transformation, so we get our new function

val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function

Again: We have a MyBox[_], and we have a flatMap function for MyBox.
This, my dear, is a Monad!

The third pattern shouldn’t be much of a problem here.

Again we start with our boxedstring, but now we found our rawLengthOf again, surprisingly itself boxed in a MyBox:


val boxedLengthOf:MyBox[String=>Int] = new MyBox( rawLengthOf _ )

But this is no problem, we only need another converter, this time without any “map” in its name.


def apply[A,B](b:MyBox[A=>B]): MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox(b.value(a.value))

apply now is a function that takes a boxed raw function and returns a new function that takes a MyBox[A], applies the unboxed raw function to its unboxed value, and returns the result in a new box.

val transformedLenghtOf = apply(boxedLenghtOf) // applying (*haha*) the transformation, to get our new function
val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function

Applicative on stage!

Let’s sum it up by listing all these transformations together. All transformations result in MyBox[A]=>MyBox[B], so I will leave this type away:


class MyBox[T](val value:T)

//Functor
 def map[A,B] ( rawfunc:A=>B ) = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )

// Monad
 def flatMap[A,B]( func:A=>MyBox[B] ) = (a:MyBox[A]) => func( a.value )

// Applicative
 def apply[A,B] ( b:MyBox[A=>B] ) = (a:MyBox[A]) => new MyBox(b.value(a.value))

So far for the basic stuff. In the next article we will talk about alternative ways to implement such concepts in Scala, so we are able to recognise them, no matter how they are implemented or how the transformation functions are named.

[1] “A Monad is a monoid in the category of endofunctors” became a popular term of debate about the usefulness of such explanations.
[2] Well, there may be more about the theoretical concept of Functors, Monads and Applicatives -and Category Theory- but that is all you need to know to start.

April 25, 2012

y ( is ( 6 afraidOf 7 ) )

Filed under: Scala, Uncategorized — de.velopmind @ 5:49 pm

Or: What happens when a simple number joke meets a bored Scala developer …

Save the following code into a file, e.g. named Fears.scala.

type Reason = () => String

class ReasonedState(val state:Boolean, val reason:Reason)

case class True(why:Reason)  extends ReasonedState(true, why) {
   override def toString() = "yes"
}
case class False(why:Reason) extends ReasonedState(false, why) {
   override def toString() = "no"
}

class Fears(value:Int) {
   def afraidOf(other:Int) = (value,other) match {
      case (6,7) => True (() => (7 to 9).toList.map(_.toString).reduce(_+" "+_))
      case _     => False(() => "nothing to fear")
   }
}

implicit def numbersFears(nu:Int) = new Fears(nu)

def is(rs:ReasonedState) = rs
def y (rs:ReasonedState) = rs match {
    case rs:True => "because "+rs.reason()
    case _       => "wrong question"
}

Then open the Scala REPL in the same directory as the file you saved and type:

scala> :load Fears.scala

Now type:

scala > y ( is ( 6 afraidOf 7 ) )

…and enjoy the result.

Tip: If you don’t already know it, read the input and the result aloud (in english).

September 4, 2011

The truth behind Scala

Filed under: Language, Scala — de.velopmind @ 5:58 pm

Now that the discussion about Scala’s complexity, mind broadening or mind twisting features and so on is on the board again with posts like

Yes, Virginia, Scala is hard (David Pollak)

and

Scala is for drivers (Michael Fogus)

I am delighted that my vacation lecture gave me the ultimate answer, why I in contrast to other fellows in development got the impression that the occupation with Scala has broadened and is further broadening my mind.

The hint to the answer is here:

Where does the name “Scala” come from?

And the answer itself  is in this quote of my lecture:

“The Winding Staircase, as it was known, […] represented man’s intellectual climb toward the Divine Truth. Like Jacob’s ladder, the Winding Staircase was a symbol of the pathway to heaven […] the connection between the earthly and spiritual realms. Its steps represented the many virtues of the mind.”

Dan Brown, you never imagined to be quoted in this context, eh?

Well. Scala is not a one-step replacement for Java. That is true, and it is good that it is.

Trying to learn Scala has indeed similarities with the Masonic degrees: Once you are initiated, you learn step by step the secret symbols and rites. Scala seems to be dangerous in the hands of the uninitiated, but it is a artefact of great power in the hands of the initiated ones.

Here are the degrees and the secrets that are unveiled when initiated to each:

Scala levels: beginner to expert, application programmer to library designer

I am happy that I came to know Scala, which, at least for me, is enlightening.

So I think, that The Lost Symbol looks like this:

(PS: Don’t take this post too serious, heh?. In the end it’s my vacation. Serious stuff is left for later).

July 16, 2011

Quicknote: Very interesting interview with M.Odersky

Filed under: Language, Scala — de.velopmind @ 4:42 pm

A very interesting interview with Martin Odersky about Scala at Dr.Dobbs:

http://drdobbs.com/231001802

Notable the hints about Scala on .Net,  for LLVM and for JavaScript.

July 10, 2010

Scripting with Scala vs. Groovy

Filed under: Experiences, Groovy, Scala — de.velopmind @ 11:21 pm

Last week I decided to challenge Scala’s downscalability by trying to replace a Groovy script with a Scala pendant.

In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor.

But first some background about the script:

Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it.

Here you see an example of such a mail (note: I have my mails displayed in plain text format):

Unfortunately the spam filter holds back most of the mails I receive from mailing lists like groovy-user, scala-user, log4j and others. Each morning I would have to open such a mail and for each kept item click on a link, wait for the browser result, close the page, go back to outlook, click the next link, and so on and so on.  Sure, this is very annoying, but a request to our IT personell did not solve the problem as it seems to be impossible to administer the white list in a way to generally let mailing list stuff through. It only works on a real sender address basis.

Well, I would not be a programmer if I would not solve the problem myself.

So I opened a Groovy console and quickly hacked a little script which let me automate the calls to the URL.

Let’s look at it in detail.

When started, the script opens a small window with a text box to insert the spam guard mail text.

On pressing the “convert” button,  a new frame opens with a line for each kept mail including a check box which is pre-selected:

On pressing the action button in this frame, the script  iterates through each line and calls the corresponding URL (well, only if the checkbox is still checked). You can follow the progress by watching the checkboxes on the right, where each processed line is marked.

So with a few clicks even a good bunch of kept mails is released automatically.

As I said, the source code is a very simple hack which I threw together in round about twenty minutes, including some book/web lookups as I have never really written a Groovy SwingBuilder based GUI before, and calling aURL was also not in my recordings.

Well, trying to rewrite this thing in Scala did not went as fast, and the result is not hundred percent the same.  But let us have a detailed look at both sources side-by-side.

I started at the beginning and developed top-down. So the first thing to look at is the method that starts the input window with the text area.

Here is how this method reads in Groovy:

def inputWindow() {
    inp = new SwingBuilder()
    frame = inp.frame(title:"Insert mailtext", size:[400,400],
                      defaultCloseOperation:WindowConstants.EXIT_ON_CLOSE) {
             panel(layout: new BorderLayout()) {
                scrollPane() {
                 editorPane(id:"mail", maximumSize: [300, 300],
                            minimumSize: [300,300], preferredSize: [300,300],
                            constraints:BorderLayout.CENTER)
                }
                button("convert", actionPerformed: {selectWindow(inp.mail.text) },
                       constraints:BorderLayout.SOUTH )
             }
    }
    frame.visible = true
}

First step is to create a SwingBuilder, which now makes it very simple to create a frame, a panel with a scrollpane containing an editor pane and a button on it and start this form. All easily done and readable due to the clear structure of SwingBuilder containment structure.

To make this code runnable we need some imports first, and here they are:

import groovy.swing.SwingBuilder
import javax.swing.*
import java.awt.*

Let’s see how Scala handles this.

First we need some imports too…

import scala.swing._
import scala.swing.Swing._

… and here’s the method:

    def inputWindow() = {
       new MainFrame {
           val mailPane = new EditorPane() { maximumSize = (300, 300);
                                             minimumSize = (300, 300);
                                             preferredSize = (300,300) }

           title = "Insert mailtext"
           size  = (400,400)
           contents = new BorderPanel {
                 import BorderPanel._
                 add( new ScrollPane ( mailPane ), Position.Center )
                 add( Button("convert"){ selectWindow(mailPane.text) } ,Position.South )
           }
       }
    }

Well, all in all this structure is as concise and as easily readable as the Groovy one. But there are some differences I want to mention here.

The first difference we see immediately is, that the mailPane is created first and stored in a dedicated variable. This is not only for code layout purposes, but necessary, as it has to be referrable later in the button’s action to get the pasted text.
In Groovy this is achieved by accessing the SwingBuilder instance, which also serves as a repository for the created components.

The next difference is, that in Scala we often create new instances with ‘new’, indeed creating anonymous subclasses this way, while in Groovy all is done by applying the builder syntax as a DSL and let the builder maintain the instance creation under the hood.  In the above code the Button is special. Instead of a ‘new’ call we see a shortcut. The button is created by applying the companion object of class Button and providing that with a code block to be executed on click.

And this was the first confusing thing for me: Some components provide companion objects, but not all. And which provide an apply method as shortcut is not clear.  One has to consult the scaladoc, and even that is often too rudimentary. In the end this shortcut option seems to be special for Button.

Another confusing thing is the way to add components to a container. Sometimes ‘add’ seemed the right way, sometimes ‘contents+=’ . But the latter does not work in a frame, where it is merely ‘contents=’ . The documentation is sparse. The Swing chapter in Programming in Scala did not answer all my questions and finding documentation on the web took me some time. After stumbling over possibly outdated, too short or academic stuff, I finally returned to  this link . It is not really a tutorial (and that’s why I stepped over it first), but an at least somewhat helpful introduction to the concepts,  and eventually it took me forward.

Ok so far about my docu experience. What now happens when clicking the button? Or better: what does method ‘selectWindow’ do?

Here I want to turn things and go bottom up first. At the beginning of selectWindow the text from the editorPane is converted into a collection of rows, containing the data and the checkbox widgets.

Let’s have a look at this job first:

Here’s the original Groovy version of the Row class:

class Row {
  def selectbox
  def date
  def address
  def title
  def url
  def donebox
}

You see, this is very concise. But Scala is close behind with its clase class construct.

    case class Row ( selectbox:CheckBox,
                     date:String,
                     address:String,
                     title:String,
                     url:String,
                     donebox:CheckBox)

This one is also a bit more helpful, as it provides the types. I could have done that in Groovy too,but due to the scriptic nature of the problem it seemed natural not to bother with such trivia. This statement will give just enough potential for long debates, I think.

But now for the conversion of a ‘text’ into a bunch of such Rows.

Again first the Groovy version:

def convert(inputtext, builder) {
    result = []
    inputtext.split("\n").each{ line ->
        matcher = line.trim() =~ /(2010\S*)\s*(\S*)\s*(.*?)\b*(Anfordern|Request) \(HTTP\)\b*.*<(.*)>.*/
        if (matcher.matches())
            result << new Row(selectbox: builder.checkBox(selected:true),
                                         title:matcher[0][3], url:matcher[0][5],
                                         date:matcher[0][1], address:matcher[0][2],
                                         donebox: builder.checkBox(selected:false))
                   // matcher[0]  [1]->date [2]->address [3]->subject [4]->wordgroup [5]->URL
    }
    result
}

And immediately the Scala solution:

    def convert(inputtext:String):List[Row] = {
        val regex = """(2010\S*)\s*(\S*)\s*(.*?)\b*(Anfordern|Request) \(HTTP\)\b*.*&lt;(.*)&gt;.*""".r
        val result = for( regex(date, address, subject, label, link) &lt;- regex findAllIn inputtext )
                         yield  new Row(selectbox = new CheckBox { selected = true },
                                        title = subject, url = link,
                                        date = date, address = address,
                                        donebox =  new CheckBox())
        return result.toList
    }

What’s notable here is that in Groovy you are in contact with such details as the matcher and its array representation, what leads to the necessity to note in a comment what index is what.
In Scala on the other hand you work on a more abstract, more declarative level, keeping such details as the match handling and the collection maintenance under the hood.

The resulting Row list of the above method is now used to construct the second frame (Groovy):

def selectWindow(inputtext) {
    job = new SwingBuilder()
    content = convert(inputtext, job)
    frame = job.frame(title:"Uncheck real spam mail", size:[800,800] ) {
         panel(layout: new BorderLayout()) {
             scrollPane(constraints:BorderLayout.CENTER) {
               panel() {
                 tableLayout {
                   content.each { row ->
                     tr {
                        td { widget(row.selectbox) }
                        td { label(text: row.title,
                                   toolTipText: "${row.date} ${row.address} ${row.title}") }
                        td { widget(row.donebox) }
                     }
                   }

                 }
               }
             }
             panel(constraints:BorderLayout.SOUTH) {
                   button("action", id: "action", actionPerformed: {process(content, job)} )
                   button("close",  id: "close",  actionPerformed: {frame.dispose()}, enabled:false)
             }
         }
    }
   frame.visible = true
}

Here we see one of Groovy’s strengths: The table layout, which lets you declare the positioning like a table in html. Very easy and handy.  Beside that, take a look at how the buttons and their actions are declared in one expression.

Now the Scala pendant:

    def selectWindow(inputtext:String) {
        val rows = convert(inputtext)
        val frame = new Frame {
           val doit = new Button("action")
           val closeB = new Button("close") { enabled = false } 

           val listPane = new BoxPanel(Orientation.Vertical) {
                              rows.foreach { row =>
                                 contents += new BoxPanel(Orientation.Horizontal) {
                                                   contents += row.selectbox
                                                   contents += new Label(row.title) {
                                                                   tooltip = row.date+" "+row.address+" "+row.title }
                                                   contents += row.donebox
                                             }
                              }
                          }
           title = "Uncheck real spam mail"
           size  = (800,800)
           contents = new BorderPanel {
                 import BorderPanel._
                 add( new ScrollPane ( listPane ), Position.Center )
                 add( new FlowPanel {
                         contents += doit
                         contents += closeB
                      },Position.South )
           }

           listenTo( doit )
           listenTo( closeB )
           reactions += {
              case ButtonClicked(`doit`)   => process(rows, doit, closeB)
              case ButtonClicked(`closeB`) => this.dispose()
           }
       }
       frame.pack
       frame.visible = true
    }

Again things are done a bit different. First, we again notice the declaration of vals for components to refer to them later (doit and closeB). Then, with listenTo(…) and reactions+= we see the reactive way of declaring actions in Scala swing.

What is important here is that Scala swing does not provide an easy to use container layout, like Groovy’s table layout. The options would have been to introduce third party things or to fiddle with a GridBag layout or such things. But to shorten the development time (which already was longer than expected due to the need to search for documentation), I decided to simply use the BoxPanel container.  The result is a bit ugly, but is usable.

We come to the “action” button now, and to method “process” which implements its action. This is now the central purpose of this whole script: For each row call the URL and check the result box.

That is how it looks in Groovy:

def process(content, builder) {
   builder.action.enabled = false
   builder.doOutside {
     content.each { row ->
       if (row.selectbox.selected) {
           def result = callURL(row.url);
           builder.doLater { row.donebox.selected = result }
       }
     }
     builder.doLater { builder.close.enabled = true }
   }
}

We see here another feature of the Groovy Swing Builder: A simple way to let code run in another thread with doOutside, and then push things back on the EventDispatchThread with doLater. This way the GUI is visibly updated for each row as it is processed, and in the end the close button is enabled.

Scala does the same this way:

    def process(content:List[Row], action:Button, close:Button) {
        action.enabled = false
        actor {
            content.foreach { row =>
               if (row.selectbox.selected) {
                   val result = callURL(row.url);
                   Swing.onEDT { row.donebox.selected = result }
               }
            }
            Swing.onEDT { close.enabled = true }
        }
    }

It resembles exactly the same structure. Instead of doLater we call Swing.onEDT. Most notably is the way to push code onto another thread. Coming from Java Swing and looking at the Groovy way to call a builder method, I first looked for a method on Swing as opposite to onEDT. Then I looked for a SwingWorker class, which indeed exists but is not documented and seems even to have no meaningful implementation(?). In the end I slapped on my head and thought “why, it’s Scala”. And indeed the natural way to run stuff on a new thread is the “actor” method. Nothing Swing specific here.

The method “callURL” now is the next step to get things done, supported by a method named “checkResult”. In Groovy this is:

def callURL(urlstring) {
    try {  def url = new URL(urlstring)
           return checkResult(url.text)
    } catch (Exception e) {
           println "Exception when Accessing URL: "+e.message
           return false
    }
}

def checkResult(content) {
    if (content =~ /Ihre Anfrage wurde verarbeitet/) {
        println "CONTENT OK"
        return true
    }
    else {
        println content
        return false
    }
}

Interesting to see that with new URL and url.text the call is done.

The Scala pendant:

    def callURL(urlstring:String):Boolean = {
        try {
           val txt:String = Source.fromURL(urlstring).getLines().mkString
           return checkResult(txt)
        } catch {
          case e:Exception =>  println ("Exception when Accessing URL: "+e.getMessage())
                                          return false
        }
    }

    def checkResult(content:String):Boolean = {
        val rgx = "Ihre Anfrage wurde verarbeitet".r
        rgx findFirstIn content match {
            case Some(x) => println ("CONTENT OK"); true
            case None    => println (content) ; false
        }
    }

Once again the structure is analogous to the Grooy one. The interesting difference here is the way to call the URL. Again it took some time to find the solution, as I first looked for what class URL might offer, but Scala simply uses the Java one. And I was led into the wrong direction by an old post which gave me the impression some time ago that object Source has to do with reading files. But after some googling I detected that I was wrong: Source is the way to go, as it is an abstraction for textual data sources, not for source files or source code.
Also the getLines() and mkString needed a bit of exploration, but in the end I got the feeling that I should have known that. I had seen this before.

Well, that was the complete program in the two languages so far. What remains is, how it is started. And here we have a big difference.

The Groovy script was … well, a script. That means, adding a line which calls the topmost method “inputWindow()” and I had a runnable script which could simply be started with e.g. “groovy releaseSpam.groovy”.

The Scala way was not as simple. Although the Scala Swing API was used to instanciate and control widgets, we miss the infrastructure so far, which we get by Groovy SwingBuilder.
To gain this, the Scala code shown so far must be wrapped inside an object which extends SimpleSwingApplication and defines a method “top” which returns the main frame.

Here is the structure:

object Main extends SimpleSwingApplication {
      // .... the code shown so far

   def top = inputWindow()
}

Normally we can now add a line at the end calling the main method like:
Main.main(Array(“”))
And run that as a script.

But that does not work together with Scala.swing and SimpleSwingApplication.
Trying to put the code in a file named “releaseSpam.scala” and call it with the scala command results in :

cmd.exe /c  scala releaseSpamMail-WIP.scala
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: Main$$anon$12$Main$
$anon$6$$anon$10
        at Main$$anon$12$Main$.inputWindow(releaseSpamMail-WIP.scala:125)
        at Main$$anon$12$Main$.top(releaseSpamMail-WIP.scala:139)
        at Main$$anon$12$Main$.top(releaseSpamMail-WIP.scala:13)
        at scala.swing.SimpleSwingApplication.startup(SimpleSwingApplication.scala:7)
        at scala.swing.SwingApplication$$anonfun$main$1.apply$mcV$sp(SwingApplication.scal
        ............

So the best way to run it is to compile it, jar it, and run the resulting jar with:
scala -cp .\releaseSpam.jar Main

At the of this article now let us talk about another aspect:  The way I programmed the scripts.

With Groovy it was a very fluent experience, as I used the GroovyConsole to continuously work in a edit-run loop and store the script when appropriate.

Scala has only the REPL, which is no adequate replacement.  I worked with Vim to get a comparable feeling, but after detecting that I cannot run code containing Swing as a script, it mutated to an edit-compile-run cycle. Well, this is also easily done out of Vim, so no real disadvantage.  But you need and external editor with good developer support to achieve that flow and that is a bit a pity.

Result:

So what is the result now?  Well, all in all Scala seems as well fit for scripting tasks as Groovy is. The code is concise and expressive and readable in both cases. But currently Groovy wins for this task, because of better documentation and/or more intuitive API,  because of Scala.swing  not including a simple layout for quick tasks, because of Scala.swing  not being runnable in a script, and because of the necessity to use an external development tool.

But if you are familiar with the API (which I am much more for the next task now), use a specific IDE tool anyway and don’t bother keeping the solution as a program instead of a script, Scala is indeed a good match. And improvements will come with further development efforts of the community, for that I am sure.

I hope you liked this little article.

February 16, 2010

How to setup NB for GAE with Scala – Part III

Filed under: GoogleAppEngine, Netbeans, Scala — de.velopmind @ 5:10 am

Additional Scala configuration for writing Servlets

To write Servlets in Scala, the Scala Project has to import at least the Geronimo Servlet Spec jar from the appengine directory. This one is sufficient to let your Scala class implement the Servlet interface.

Add Servlet-Spec Jar

Step 1: Select “Add Jar/Folder” in the context menu of the Libraries entry in your Scala project tree. Go to the lib/shared folder of your app-engine SDK installation.

Step 2: Select the geronimo-servlet-spec.jar

Write Test servlet in Scala

In the Scala project in our package testapp create a new Scala class named e.g. MyScalaServlet, and put in the following code example:

package testapp

import javax.servlet.http.{HttpServlet         => HServlet,
                           HttpServletRequest  => HSRequest,
                           HttpServletResponse => HSResponse}

import java.io.PrintWriter;
import scala.xml.Elem

class MyScalaServlet extends HServlet {

  def processRequest(request:HSRequest, response:HSResponse) {

        val theTitle = "A first Scala Servlet"

        val content = (
              <html>
                <head>
                  <title>{theTitle}</title>
                </head>
                <body>
                  <h1>{theTitle}</h1>
                  <p>
                    is at: {request.getRequestURL()}
                    </p>
                </body>
              </html>
        )

        writeContent(response, content)
  }

  def writeContent(response:HSResponse, cont:Elem) {
        response.setContentType("text/html;charset=UTF-8")
        val out:PrintWriter = response.getWriter()
        try     { out.println(cont) }
        finally { out.close() }
  }

  override def doGet(request:HSRequest, response:HSResponse) {
      processRequest(request, response);
  }
}

I should mention that at the time of this writing there seems still to be a little bug in the Scala plugin which results in the first import displayed as erroneous. The message is: value servlet is not a member of package javax.

Truth is, you can simply ignore this message and build the project as usual.

Well, the source above is a little example of Scala’s features and how a servlet may look like in Scala. But this is only one way to create Scala servlets, and except for the embedded XML/HTML stuff it is very close to a Java solution. You may come up with better and more sophisticated solutions, or find some in the internet.

So far that’s fine. We now only have to configure the Servlet in the Web Application’s web.xml file

Select the web.xml file in the configuration files folder of the Web Application project and double click it to open.

Now you get a form based editor for the different parts in the configuration file. Select Servlets and click Add Servlet Element . You should see an input form, which you can fill like in the following example:

Please note that the Browse button won’t work in this scenario, as the source is not located in this same project. So the full qualified servlet class name has to be inserted manually.

After pressing OK and rebuilding/deploying the WebApp project, you can see the result by calling the following URL in your browser: http://locahost:8080/test/scalaservlet

The End

I hope you enjoyed this little tutorial about Scala in Netbeans for the Google App Engine.

If you want to go further into using the app engine services –for example the persistence–, you will need further libraries which are configured in the same way like described above for the geronimo jar.

For tutorials about using e.g. JDO or JPA with Scala look for other sources in the internet, as this exceeds the topic for this little howto.

The basics are laid out, now it’s your turn!

Older Posts »

Blog at WordPress.com.