As you can expect Io lends itself very naturally to defining DSLs due to its proverbial flexibility – after all the ability to change practically everything what it does, allows you to change the nature of Io to your specific problem domain.

In book this is explained through a simple example of defining a DSL in 13 lines of code that allows map definition in JSON like syntax. Homework 2 sets a similar but simpler goal of defining a syntax based on brackets that allows definition of lists. So here it is:

HW2: Create a list syntax that uses brackets

squareBrackets := method(
    call message arguments map(value,
        self doMessage(value)
    )
)

aList := [1, 2, 30, "forty"]
aList println
aList at(3) println

I have added squareBrackets slot that gets invoked when square brackets are encountered in the environment. This means that my method will be invoked when parser comes across [] pair. Once invoked the method inspects the activation to fetch arguments passed, arguments are then simply mapped into a list of their evaluated values.

After a quick scan of the reference documentation I noticed that Call prototype has an evalArgs method that will do it all for me. By using it solution becomes almost embarrassingly simple, so I have also added support for retrieving list elements by using square bracket notation by defining squareBracket slot on List prototype. This method gets invoked when square brackets are encountered in scope of an object cloned from List.

squareBrackets := method(call evalArgs)

List squareBrackets := method(index, self at(index))

aList := [1, 2, 30, "forty"]
aList println
aList[3] println

Another neat trick Bruce shows for tackling DSLs is redefining the “forward” method. This is the method that gets invoked when an object receives a message and doesn’t have a corresponding slot. As mentioned in day1 article the usual implementation of forward searches object’s prototypes trying to find a matching slot, but as it is just a method it can be replaced with a different functionality all together. This mechanism is then exploited to redefine a forward method on a Builder object in order to allow us to expres XML in Lisp-ish syntax. The example provided is then used as a base for two homework assignments.

HW1: Enhance the XML program to add spaces to show the indentation structure.

#!/usr/bin/env io

Builder := Object clone do(
    indent := 0

    forward := method(
        indentedText := method(text,
            "  " repeated(indent) .. text
        )

        indentedTag := method(tag, open,
            indentedText(if(open, "<", "</") .. tag .. ">")
        )

        indentedOpenTag := method(tag,
            indentedTag(tag, true)
        )

        indentedCloseTag := method(tag,
            indentedTag(tag, false)
        )

        writeln(indentedOpenTag(call message name))
        indent = indent + 1
        call message arguments foreach(arg,
            content := doMessage(arg)
            if(content type == "Sequence",
                writeln(indentedText(content))
            )
        )
        indent = indent - 1
        writeln(indentedCloseTag(call message name))
    )
)

Builder ul(
    li("Io"),
    li("Lua", ul(li("Ioke"), li("Self"))),
    li("JavaScript")
)

The first part of the forward method defines some internal helper methods to deal with indentation (I like how you can limit a scope like that), the second (business) part of method the inspects call object introduced in day 2 and renders the XML.

HW3: Enhance the XML program to handle attributes: if the first argument is a map (use the curly brackets syntax), add attributes to the XML program. For example: book({“author”: “Tate”}…) would print <book author=”Tate”>

#!/usr/bin/env io

OperatorTable addAssignOperator(":" , "atPutProperty" )

curlyBrackets := method(
    aMap := Map clone
    call message arguments foreach(arg,
        aMap doMessage(arg)
    )
    return aMap
)

Map atPutProperty := method(
    self atPut(
        call evalArgAt(0) asMutable removePrefix("\"") removeSuffix("\"" ),
        call evalArgAt(1)
    )
)

Map asAttributes := method(
    self map(k, v, " #{k}=\"#{v}\"" interpolate) join
)

Builder := Object clone do(

    indent := 0

    forward := method(

        indentedText := method(text,
            "  " repeated(indent) .. text
        )

        args := call message arguments
        tag := call message name

        write(indentedText("<" .. tag))
        if(args first name == "curlyBrackets",
            write(doMessage(args first) asAttributes)
            args = args rest
        )
        writeln(">")
        indent = indent + 1

        args foreach(arg,
            content := doMessage(arg)
            if(content type == "Sequence",
                writeln(indentedText(content))
            )
        )

        indent = indent - 1
        writeln(indentedText("</" .. tag .. ">"))
    )
)

doRelativeFile("lispML.txt")

lispML.txt:

Builder ul(
    li(
        ul({"paradigm":"Object Oriented", "typing":"Dynamic"},
                li("Io"),
                li("Ruby"))),
    li (
        ul({"paradigm":"Object Oriented", "typing":"Static"},
                li("Java"),
                li("C#"))))

So let me try to give brief explanation of what is happening here. The bit of code on the top relating to operators, Map and curly brackets will parse JSON like Map definition and expose it as a string representing the XML element attributes. By now it should be fairly straightforward to understand. The Builder’s forward method was changed to check if the first argument is a “curlyBrackets” message. If it is it receives special treatment by being converted to string representing element attributes and written to opening tag. The rest of the arguments get treated in the usual manner as in HW1.

There is a caveat which wasted a fair bit of my time (and other peoples too). When you update OperatorTable within the file, you are not changing semantics of the current file as the table was already read. So the changed behaviour only applies to any subsequently parsed files (or strings). This is why there is a separate lispML.txt file.

Next subject that book tackles is concurrency. As I expected by now Io has a very simple yet elegant approach to concurrency. From concurrency point of view every object can be seen as an actor. Messages can be passed to actors (objects) by prepending them with @ or @@. If a message is prefixed with @ it will be sent to actor’s queue and a future will be returned. Future object will become a result once the result is available. If it’s value is requested and result is not yet available it will block until it is. If a message is prefixed with @@ it will be put on actor’s queue and nil will be returned immediately.  When processing the message actor will start a coroutine which will process it asynchronously. That is pretty much all there is to it – simples. There were no homework assignments regarding concurrency but I might revisit this area to provide an example.

Let me try to sum up my impression of the Io after this brief encounter. The language is very simple and flexible (you could almost say it’s liquid like). Which I found to be a very good trait as it tries to get out of your way as much as possible and lets you do with practically  anything you can possibly come up with. This makes it exciting and fun to work with. On the flip side there is not that much of resources available for Io. And sometimes you are left wondering and trawling through mailing lists and lurking on IRC channels. Thankfully this doesn’t happen that often due to intrinsic simplicity and decent documentation on iolanguage.com which is very simple and minimal in true fashion of the language. As expected of such a dynamic language the single thread performance leaves much to be desired.

I am sure I will be returning to Io, if nothing else when working on some hobby code. Working with Io is just too much fun to leave it aside. Long live the clones!

In conditionals and looping section we get overview of some typical looping and branching structures. Such as a simple infinite loop that will keep evaluating until a break:

loop("you spin me right round..." println)

This can come in handy when implementing things such as servers etc. We also get to meet our good old friends (often seen in most languages) for and while loop:

i := 1
while(i <= 10, i println; i = i + 1)

for(i, 1, 10, i println)

for(i, 10, 1, -1, i println)

First two lines are an example of a while loop. It will print numbers from 1 to 10. While loop takes a condition as a first parameter and it will keep evaluating statements passed in second parameter while the condition holds. Lines 4 and 6 are examples of a for loop. First one prints numbers from 1 to 10 and second one counts back from 10 to 1. This is due to the fact that second for loop utilises the optional step parameter. The parameters of a for loop method are: the name of the counter, the first value, the last value, optional step, and a message with sender. As we can see from example step parameter can be negative.

Next we learn about if method whose basic form is: if(condition, true code, false code) and that it if comes in following two flavours:

if(true, "It's true" println, "It isn't true" println)

if(true) then(
    "It's true" println
) else(
    "It isn't true" println
)

The syntax of first option is if(condition, true code, false code). The second option is self explanatory, I hope.

You might have noticed that I refer to “for”, “while” and “if” as methods. Which is in fact exactly what they are, as there are barely any keywords in Io due to its minimal syntax. All of them are merely methods defined on Object object.

Next we move to operators which as you might have guessed by know are again just methods. All of the operators are defined in OperatorTable object which also holds operator precedence data. So to add a new operator all we have to do is add the operator to the table and define the method on the objects that we wish to support the operator on. Example based on logical implication:

// hint: type OperatorTable in Io console for list of all
// supported operators and their precedence

OperatorTable addOperator("=>", 12)

true => := method(bool, bool)
false => := true

We then proceed to learn a bit about message passing and reflection. Every message has three components: sender that sends the message, target that executes the message and arguments. We learn about the fact, that we can access all the information about the current message via “call” method exposed in each block (method). This method provides access to Call object which stores information and methods related to currently executed method . For instance this is the way to access message name and arguments:

mirror := Object clone

mirror reflect := method(
    call message name println
    call message arguments println
)

Io> mirror reflect(1, "two", 3)
reflect
list(1, "two", 3)
==> list(1, "two", 3)

Armed with this knowledge we are asked to tackle 8 “homework” tasks:

HW1: A Fibonacci sequence starts with two 1s. Each subsequent number is the sum of the two numbers that came before: 1, 1, 2, 3, 5, 8, 13, 21, and so on. Write a program to find the nth Fibonacci number. fib(1) is 1, and fib(4) is 3. As a bonus, solve the problem with recursion and with loops.

fib := method(n, if (n < 3, 1, fib(n - 2) + fib (n - 1)))

fibIter := method(n,
    previous := 1
    current := 1
    for (i, 3, n,
        buffer := current
        current = previous + current
        previous = buffer
    )
    return current
)

for (i, 1, 10, "rec:#{fib(i)} iter:#{fibIter(i)}" interpolate println)

I am used to programming in iterative style but I must say that this task lent itself naturally to recursion, which lead to a very simple one liner. Both methods rely on the fact that there is no need to calculate first 2 positions and 1 can be returned in that case. Armed with first 2 positions calculating the rest of the sequence is trivial.
In recursive variant you can also see that I rely on the fact that return method (yep method again) is optional. If you don’t provide it method will simply return the value of the last evaluated statement.

HW2: How would you change / to return 0 if the denominator is zero?

Number originalDivision := Number getSlot("/")

Number / := method(denominator,
    if (denominator == 0, return 0, self originalDivision(denominator))
)

(1 / 2) println
(1 / 0) println
(2 / 1) println

I found this task quite interesting as I was wondering how to change the existing method without overwriting it. The solution I came up with is to just simply store original method in a new slot and redefine the division slot. The newly defined division slot then treats the exception when denominator is 0 and passes “business as usual” calculation to the original method.

HW3: Write a program to add up all of the numbers in a two-dimensional
array.

sum2d := method(array, array flatten sum)

sum2d(list(list(1, 2, 3), list(1, 2, 3), list(1, 2, 3))) println

This one almost falls under the easier done than said section. First list is flattened into single dimension and then sum of flattened list’s elements is returned. Easy peasy.

HW4: Add a slot called myAverage to a list that computes the average of all the numbers in a list. What happens if there are no numbers in a list? (Bonus: Raise an Io exception if any item in the list is not a number.)

List myAverage := method((self sum) / (self size))

List myAverage1 := method(
    self map(element, if (element type == "Number", element, 0)) myAverage
)

List myAverage2 := method(
    sum := 0
    counter := 0
    self foreach(element,
        if (element type != "Number", Exception raise("Not a number element"))
        sum = sum + element
        counter = counter + 1
    )
    sum / counter
)

a := list(1, 2, 3, 4, 5, 6, 7)

a myAverage println
list("a", "b", "c") myAverage1 println
a append("a")
a myAverage1 println
list(1,2,3) myAverage2 println
a myAverage2

I have solved this task in three different ways.
First relies on methods provided by List prototype. It is very simple and reads well but it doesn’t handle non number elements.
Second option first maps the List into a new List where non Number elements are replaced by 0 and then invokes “myAverage” method on it.
Third option is the most verbose but I wanted to solve the problem with counters as well.

HW5: Write a prototype for a two-dimensional list. The dim(x, y) method should allocate a list of y lists that are x elements long. set(x, y, value) should set a value, and get(x, y) should return that value.
HW6: Bonus: Write a transpose method so that (new_matrix get(y, x)) == matrix get(x, y) on the original list.
HW7: Write the matrix to a file, and read a matrix from a file.

List2d := List clone do(
    dim := method(x, y, self setSize(y) mapInPlace(list() setSize(x)))

    set := method(x, y, value, self at(y) atPut(x, value))

    get := method(x, y, self at(y) at(x))

    transpose := method(
        newX := self size
        newY := self first size
        newMatrix := List2d clone dim(newX, newY)
        for(x, 0, newX -1,
            for (y, 0, newY -1,
                newMatrix set(x, y, get(y, x))
            )
        )
        return newMatrix
    )
)

setAndDisplay := method(matrix, x, y, value,
    matrix set(x, y, value)
    matrix get(x, y) println
    matrix println
)

matrix := List2d clone dim(3, 2)
matrix println

setAndDisplay(matrix, 0, 0, 5)
setAndDisplay(matrix, 1, 0, 10)
setAndDisplay(matrix, 2, 0, 15)

setAndDisplay(matrix, 0, 1, 20)
setAndDisplay(matrix, 1, 1, 25)
setAndDisplay(matrix, 2, 1, 300)

setAndDisplay(matrix, 2, 1, 30)

matrix transpose println

File with("matrix.dat") open write(matrix serialized) close
matrix = nil
matrix println
matrix := doRelativeFile("matrix.dat")
matrix println

“dim” method does the job by setting the size of the main list to y, as task prescribes. Next “mapInPlace” method is used to update each element of that field by setting it to a list with size of x. Beautiful. I will not explain “set” and “get” methods as I think they are easy enough to understand.
“transpose” method works on the principle of inspecting a List2d that we’re transposing and creating a new instance with swapped dimensions. Iterating through the elements and swapping their coordinates does the rest of the job.
In regards to saving a matrix to a file and reading from it, I resorted to simple serialization. As Io serializes its objects into Io scripts, all I have to do to deserialize matrix from the file is to execute the contents of the file by virtue of “doRelativeFile” method.

HW8: Write a program that gives you ten tries to guess a random number
from 1–100. If you would like, give a hint of “hotter” or “colder”
after the first guess.

number := Random value(1, 100) round
previousDif := nil

loop(
    guess := File standardInput readLine("Take a guess: ") asNumber

    if(guess isNan, continue)
    if(guess == number, break)

    dif := (number - guess) abs

    if(previousDif,
        if(previousDif > dif) then(
            "Warmer" println
        ) elseif(previousDif < dif) then(
            "Colder" println
        ) else(continue))

    previousDif = dif
)

"You da man" println

I don’t think there is much need to spend too many words on this task. It is quite self explanatory. The only new concepts introduced are generating a random number and reading from standard input, but they are very straightforward as you can see.

If I try to sum up my impressions after day 2 I must say that I am still finding it hard to wipe the smirk of my face when playing with Io. It is just so full of pleasant surprises and combined with the simplicity of the language it is hard for any self confessed geek not to like it IMHO.

Happy cloning!!

So let me sum up my thought after day one with Io. You might not heard about this language before as it is not as popular or well known as others mentioned in the book. Io is an object oriented prototype language. This means that it doesn’t have the notion of a class as an object template meaning that there is no distinction between classes and instances – all object are merely clones of other objects. The language is very simple and syntax is minimal. Objects are created by cloning like this:

Food := Object clone

As mentioned the language is not very widespread hence no syntax highlighting. Objects are nothing more than a collections of “slots”. Slots can hold values or methods both of which are objects and this is how slots are created:

Food description := "Something to eat"
Food eat := method("Yum!" println)

First line defines a “description” slot that holds a value and second line defines an “eat” slot that holds a method. When message is passed to an object object is checked whether it contains a slot with that name. If it does it will either return a value or invoke the method held in the slot. If it doesn’t, then its protoype (object it was cloned from) and its prototypes are search for the matching slot and that one gets invoked if it exists. Otherwise an exception gets raised. This means that if we clone Food object to create pizza and define description and shape slots we get following behaviour:

Pizza := Food clone
Pizza description := "Flat bread with toppings"
Pizza shape := "Round"

Io> Pizza description
==> Flat bread with toppings
Io> Pizza shape
==> Round
Io> Pizza eat
Yum!
==> Yum!

What I find very amusing about this is that we can change slots and prototypes at run time, which shows the malleability of language and makes it feel like working with putty. For instance let’s assume Pizza is also a programming language (which is an unorthodox but not a completely insane idea). Not a problem – new ProgrammingLanguage object needs to be cloned and it has to be added to list of Pizza’s prototypes.

ProgrammingLanguage := Object clone
ProgrammingLanguage description := "Something to use for programming"
ProgrammingLanguage paradigm := "generics, algebraic types"
ProgrammingLanguage eat := "It's silly to try to eat a language"

Pizza appendProto(ProgrammingLanguage)

Io> Pizza description
==> Flat bread with toppings
Io> Pizza paradigm
==> generics, algebraic types
Io> Pizza eat
Yum!
==> Yum!

We have just proven of Io’s flexibility and at the same time seen how it deals with multiple inheritance. If an object does not have a slot that would respond to the message passed to it, it will search it’s prototypes using depth first algorithm. That’s why Pizza will search it’s own slots when trying to respond to a message, if it can’t find a match it will try Food’s slots. If it can’t find a match there either, it will search Food’s prototype – Object. After it has gone full depth on first prototype (Food) and it still hasn’t found an appropriate slot, it will try the next prototype (if present), which in our case is ProgrammingLanguage. And so on… This is how “paradigm” message gets resolved on Pizza object in our example.

“Homework” is really simple at the end of the first day with Io. Probably due to the fact that it is not completely trivial to install.

First task is to run an Io program from a file. Which is just the same as running a ruby script. If you write your application in a file called HelloWorld.io, you can run it like this:

$io HelloWorld.io

It is also possible to make script executable on *nix systems by marking file as executable and adding a shebang to the top of the file like so:

#!/usr/bin/env io

"Hello Cruel World!" println

Second task is executing the code in a slot given its name. It’s almost easier done than said.

Io> Pizza perform("description")
==> Flat bread with toppings

Thus far I am very impressed by Io. Exploring it just brings a smirk on my cheeks and what I’ve seen so far makes me quite excited at the prospect of finding out what’s next on its agenda. I think having that much fun, must be worth something, even if I might never get to do anything productive with the language.

Well I hope on day 2 Io will show more of its tricks…

Then new languages that run on JVM started gaining traction and I had a little play with Groovy couple of years ago. I liked the language very much and I grokked why my friends were so happy with Ruby path they’ve chosen. Sheer expressiveness and productivity provided were impressive. I tried to push for Groovy to be used at work but it never got beyond utilities and scripts. I once read that someone said that the problem Groovy has, is that it is not called Business Logic Expression Language. It seems that sentiment rings quite true.

Anyway as I mentioned earlier Java no longer feels quite like a nice new comfy shirt. I am feeling that it’s constraining me and due to my brushes with alternative, there is always that little question in the back of my head: “Am I using the proverbial golden hammer?”

Recently I started looking over the fence again and I am seeing that there seems to be more choice than ever. One of the languages that sparked my interest was Scala. I checked out some of the websites devoted to it and found that community seems quite vibrant and that the language itself is very interesting indeed. Also the fact that it allows and encourages functional programming sparked my interest even further. I am quite familiar with object orientation and have merely brushed with functional programming at uni. The prospect of getting my head around something new and the promises that functional programming paradigm brings (especially regarding concurrency) got me quite excited.

As I almost decided to devote more time to Scala I have attended Agile Testing & BDD eXchange. In one of the presentations Erik Stenman talked about Erlang amongst other things and caught my attention.

Now I knew I have a problem. Too many languages and too little time. I realised that before I commit to a single language I want to have a bit of a nose around the programming languages landscape. So I thought, wouldn’t it be great if there was a book that would give you a crash course in several languages. Nothing too deep – only enough to present you the language’s philosophy and give you a feel of the language. Preferably these languages should cover different paradigms so that I could evaluate them as well and try to understand their strengths and weaknesses as well.

Well guess what a bit less than a month ago The Pragmatic Bookshelf have published Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages by Bruce A. Tate. From a bit of scan reading it seems that book is almost a perfect fit to my requirements. It promises to take you on a journey through seven languages in seven days (I’ll see if I can keep up) and languages are chosen to give you a flavour of object orientated programming, function programming, prototype based OO, logic programming and hybrids.

I will try to keep up with the program and tackle a new language each week. For those interested in my progress and findings I intend to blog about them as I go along. Wish me luck on my journey of discovery.