Archive for the 'IoLanguage' Category

Build Io on Fedora Core 5

Thursday, July 27th, 2006

Following in my own footsteps — yes, it is a recursive process — here are the steps required to install Io on Fedora Core 5.

sudo yum install freeglut-devel pcre-devel libevent-devel

Once again, libsgml needs a special treatment:

> wget
> tar xfz libsgml-1.1.4.tar.gz
> cd libsgml-1.1.4
> ./configure
> make

At this point, you will need to edit the Makefile. Replace:

install -m 644 -o root -g root --directory /usr/local/include/sgml


install -o root -g root --directory /usr/local/include/sgml
install -m 644 -o root -g root include/Variant.h \

Save your modifications and proceed with:

> sudo make install

Finally, to download, build and install Io:

> sudo yum install darcs
> darcs get
> cd Io
> make
> sudo make install

Enjoy Io!

technorati tags:, ,

Io podcast

Thursday, July 27th, 2006

Rodney Ramdas, from pinupgeek, recorded the first episode of the Io podcast. His guests are Steve Dekorte, Io’s creator, and Jonathan Wright (aka quag) who does the night shift. It can’t get any better in the Io world!

Good luck Rodney for the podcast!

technorati tags:,

Build Io on Ubuntu Dapper

Thursday, July 27th, 2006

The Io language has a brand new build system. Gone is the static linking, Io is now dynamically linked. I believe the build system is far better than its predecessor.

It will need a couple of iterations to iron out a couple of problems. The detection of the dependencies for the bindings needs a small revision: it only checks for the libraries, not the header files. This is problematic on debian based system where, traditionally, a library X is in a package named libX and the header files in libX-dev.

If you want to experience Io on Dapper, you will have to do the following:

> sudo apt-get install build-essential
> sudo ldconfig

To get the SGML binding working, you will have to get your hands dirty with libsgml. Here is how:

> wget
> tar xfz libsgml-1.1.4.tar.gz
> cd libsgml-1.1.4
> ./configure
> make

Before going any further, you need to edit the Makefile and change the first line of the install target from:

install -m 644 -o root -g root --directory /usr/local/include/sgml

into this:

install -o root -g root --directory /usr/local/include/sgml
install -m 644 -o root -g root include/Variant.h \

Don’t ask… Finally, to install libsgml in a relatively clean way, I suggest using checkinstall like this:

> sudo apt-get install checkinstall
> sudo checkinstall

The stage is ready for Io:

> sudo apt-get install darcs
> darcs get
> cd Io
> make

May the cloning begin!

technorati tags:,

Updated on 05/09/06: fixed typo, thanks to Jesse’s comment.

Little manual of cloning for Io programmers

Monday, March 20th, 2006

Today, we will continue the little stroll around the Io language landscape that we started in Blame it on Io! A slow-paced introduction to the Io language. We will delve deeper into the central principle of prototype-based languages: cloning.

Cloning crash course

For the mad scientists and other evil dictators who landed here after googling “manual of cloning”, here is a crash course in object creation, à-la Io:

Movie := Object clone

original := Movie clone
original title := "Island of Lost Souls"
original year := 1933
original scenario := "Mad scientist off-shores
    development of mutant race"

remake := original clone
remake title = "The Island of Dr Moreau"
remake year = 1977

remakeOfRemake := remake clone
remakeOfRemake year = 1996

Object creation in Io, like Polka, is a two step dance: 1. you clone, 2. you specialize.

Differential inheritance

As we have just seen, cloning an object is done by sending it the clone message. This allows for a very elegant implementation of the Singleton pattern:

GeorgeClooney := FamousActor clone
GeorgeClooney clone = GeorgeClooney

Bad news for my wife… but I digress.

To really understand cloning, it is necessary to look at how an object is implemented. I will spare you the details of the struct definition (see vm/IoObject_struct.h if you really want to know) by remaining at a conceptual level. Io objects are made of two ingredients: slots and prototypes. Slots are stored in a hash table and represent both the data and the methods of the object. Prototypes are stored in a list and are the ancestors of the object — more on why this is a list in the next section.

How does this all fit together? Well, when a message is sent to an object, its name is used to query the slots hash table of the object. If no slot is found, the operation is repeated for each prototype in the prototypes list. When a matching slot is found, it is activated. If no slot is found, the forward slot is activated. If no forward slot is found, then you get an error. This will clarify:

JeanClaudeVanDamme := FamousActor clone
JeanClaudeVanDamme act

will raise: Exception: Importer Object does not respond to 'act', whereas:

KeanuReeves := FamousActor clone
KeanuReeves forward := method(
    writeln("I know ", call message name))
KeanuReeves kungfu

will even pretend that Keanu Reeves can act.

Now, back to our first question, what happens when an object is cloned? Very little actually: a new object is created with an empty slots hash table and a prototypes list containing the target of the clone message. By default, a clone delegates everything to its original. Once it is created, a clone is usually specialized by adding slots in its slots hash table. The clone only stores the difference with its original. This is called differential inheritance.

Clones sharing memories with their original, not only makes bad hollywood movies (The Island and Replicant), it is not always desirable:

Movie := Object clone
Movie cast := List clone

would lead to all movies sharing the same cast! You could fix the problem by initializing the cast slot to a freshly cloned list on every Movie clone, but this would be error-prone and very inelegant. This is where the init slot comes into play. It is activated, if it is present, just after the creation of the clone. Let’s rewrite the previous piece of code:

Movie := Object clone
Movie init := method(self cast := List clone)

Note that self is required, otherwise the cast slot will be local to the method.

Future directions

This is the current state of affair in Io. But things might change, Steve Dekorte, the mad scientist behind Io, identifies 5 different cloning strategies with regards to slots:

  1. nil: the slot is set to nil in the clone — init := method(self foo = nil)
  2. shared: the slot is not created in the clone — the current default behaviour
  3. shallow: the slot is created with the original’s value — init := method(self foo = foo)
  4. deep: the slot is created with a clone of the original’s value — init := method(self foo = foo clone)
  5. very deep: the slot is created with a deep clone of the original’s value — init := method(self foo = foo deepClone)

It is probable that support for each strategy will be added to Io at some point. For now, you have to use the init slot to implement these strategies.

Dynamic inheritance with Protos

Let’s come back to the prototypes list. From what I have explained so far, it seems objects can have only one parent, the original. A list looks superfluous. Great news for my mad-scientists readers: the answer does not follow the laws of biology. Io makes it possible to add and remove parents to an object, at runtime, using appendProto, prependProto, removeProto and other related methods. These methods simply manipulate the list of prototypes associated with an Io object.

LukeSkywalker := Person clone
LukeSkywalker appendProto(Orphan)
LukeSkywalker fightsWith(DarthVader)
DarthVader tellsSecretTo(LukeSkywalker)
LukeSkywalker removeProto(Orphan)
LukeSkywalker appendProto(DarthVader)

And this concludes today’s stroll! I hope you found it informative and entertaining. I would like to thank everyone on the #io channel for your patience in dealing with my questions. Most, if not all, of the information contained in this post comes from chats on IRC and from the Io documentation. I’ll only claim the silly examples!

Blame it on Io! A slow-paced introduction to the Io language

Wednesday, March 15th, 2006

No posts in a week, I have been silent too long. Blame it on Io!

You see, Io is a contagious disease. It affects programmers’ brains. The incubation period is extremely short, due to the simplicity of its syntax. But the damages are extensive, particularly for Algol-derivative programmers: you will end up messed up! Huh… I forgot to mention the vectors include reading posts about Io. I just hope your infection will not be as bad as mine. (If I do not get google hits from E.R. fans with this paragraph, what will it take?)

Yo Io!

First things first, let’s get the token “Hello World!” implementation out of the way:

"Yo Io!" print

Aside from my poor taste in greeting phrases, you probably noticed how concise and simple this statement is. At first sight, to most programmers, it appears to be written backward. Not so if you think that the "Yo Io!" object — which happens to be a string — is being sent the message print. Everything in Io is an object, and I really mean everything: lists, files, strings, numbers and even messages!

Attack of the clones

Well that is not fully accurate, to be pedantic, I should have written: everything in Io is a prototype. Indeed, Io is a prototype-based language. C++/Java/C# programmers, here comes surprise #1: Io knows nothing about classes. In class-based languages, classes describes the structure and behaviour of objects in term of methods whereas instances hold the objects’ data. Prototype-based languages do not make this distinction. A prototype is both a class and an instance. To get a new instance, you clone an existing prototype. To get a new class you add or alter the behaviour of an existing prototype. Sounds complex? Let your inner mad scientist free:

Sheep := Object clone

In English, Sheep is defined as a clone of Object — the parent of all Io prototypes.

Sheep legCount := 4

In brain-damaged English, the legCount property of a Sheep is defined as four. Non-programmers would have you believe this is equivalent to: a sheep has four legs.

MutantSheep := Sheep clone

A MutantSheep is defined as a clone of a Sheep. No surprise here, we all knew that!

MutantSheep legCount = 7

But their legCount property is set to seven! Most inner mad scientists tend to go for six legs, but my inner mad scientist is also nonconformist. I explain the difference between = and := in the next section. Just pretend they are the same for the moment.

dolly := MutantSheep clone

Here be dolly the mutant sheep! The convention is to use an upper-case character at the beginning of the name of prototypes acting as classes and a lower-case character for prototypes acting as instances.

Lots of slots

Once again, I have to confess that I have been inaccurate: I wrote legCount was a property of a Sheep whereas, in Io speak, it is actually a slot of Sheep. A slot associates a value to a name within the context of a prototype. Sheep holds one slot named legCount with the value 4. Here comes surprise #2: slots can contain variables and methods.

Sheep baa := method("bah!" print)

The baa slot on Sheep is defined as a method which prints “bah!”. Simple, no?
You noticed earlier that Io has two different assignment operators: := and =. Both of them are actually methods on Object. := is actually parsed as setSlot and = is parsed as updateSlot. From the method names you probably inferred the difference: := creates a new slot on a prototype from a name and a value whereas = updates an existing slot with a new value.
Io interprets the previous code sample like this:

Sheep setSlot("baa", method("bah!" print))

There is madness to Io’s methods

In case you were wondering, method is a method on Object that creates anonymous methods. The self-referential aspect of what I just wrote surely enlightened you, not. Rewind. Slow motion. The method method takes a list of parameters. All but the last one are arguments to the created method. The last argument is the body of the method. In this example, I define the growMoreLegs slot on MutantSheep to be a method with one parameter:

MutantSheep growMoreLegs := method(n,
    legCount = legCount + n)

Apart from the slightly surprising syntax, I hope this all sounds pretty familiar so far. Things are about to change big time! Surprise #3: a method can control when and if to evaluate an argument. This lets us define flow control constructs (if, unless, while, etc.) as methods. Most of them already exist on Object of course. One construct is missing though and we will implement it here. But first, we will botch the job:

Object unless := method(cond, then, else,
    if(cond, else, then))

The problem: cond, then and else are evaluated when unless is called. We do not want that. What we want is: unless cond is true, evaluate then, otherwise evaluate else. In Io this is done like this:

Object unless := method(
    if(call eval argAt(0),
        call eval argAt(2),
        call eval argAt(1)))

Update: see jer’s comment for a better implementation
What looks like a nice trick, is actually extremely powerful. Lisp programmers laugh in the background, they’ve used it successfully since 1958! I will not explore this vast topic any further in this post — I must save some ammunition for future posts!
By the way, I hope you appreciated the fact that Io is a dynamic language: we just added a method to the Object prototype!

Lobby for Io!

Before concluding, I would like to point out that Sheep and MutantSheep are defined like slots. But what is the underlying prototype? In Io, this is the Lobby. So what? Well, Lobby ultimately derives from the Object prototype, like all other prototypes. But where do you think we found the Object prototype? Bingo! It is a slot in the Protos slot of Lobby. I suggest you read this again. You are not dreaming: Object is both a slot of a slot in the Lobby and an ancestor of the same Lobby. How is that for another self-referential bit of self-reference?

Time to conclude, I hope this introduction will entice you to dwell deeper into this really amazing language. Believe me, we have only scratched the surface!
For a more complete, formal and accurate presentation of Io, check out The Io Programming Language.
Visit the official website or join the posse on

Metaprogramming, Java’s downfall

Monday, February 20th, 2006

I have been a Java developer for almost 10 years and I must admit I really enjoy coding in Java. When I first discovered it, I was amazed by its API, the quality of its documentation, its simplicity and most of all its portability. With experience came a better understanding of the Java philosophy and a deeper understanding of Object Oriented concepts. Lately though, I have found Java to be a limiting factor to my productivity. I have identified the main reason behind this: Java lacks metaprogramming. Briefly put,metaprogramming is writing programs that write programs (see metaprogramming on wikipedia).

Here is an illustration of the problem. Everytime I want to write a JavaBean object, I have to make the class serializable, make sure the class has a default constructor, write getters and/or setters for all properties, write methods to register and unregister listeners for the bound properties, etc. It has to be done for every single bean you ever write. Coupled to the fact that unit tests for getters and setters are rarely written, leads to a very error prone process. It is easy to see that there is a definite pattern to this extremely repeatitive task, and obviously there are ways to ease the pain. Code generating tools like xdoclet and eclipse for example, do a decent job in this case. However, these tools suffer because they each use their own templating language and their functionality is usually limited to a C/C++ macro style of behaviour, agnostic of the language itself. By contrast, in a metaprogramming language, this templating and the code it generates are implemented in one language only. It is therefore possible to extend the language itself, by adding new constructs, rather than just develop the object hierarchy.

LISP is probably the quintessential metaprogramming language. LISP’s macros are so powerful that it has been able to adapt and incorporate every new programming paradigm. To my knowledge (and wikipedia’s), LISP (1958) predates all OO languages, as the concept was only being born, and yet CLOS is implemented in LISP itself and supports some features that other OO languages can only dream of (multiple dispatch for example). When AOP came about, it did not take long for LISP to have its own implementation: AspectL.

People usually object that LISP is unreadable. I suppose we will all agree that parentheses, like everything in life, must be used in moderation. But metaprogramming does not have to be implemented in a heavy and unreadable way. In order of increasing readability, I will point you to Io and to Ruby. Ruby uses metaprogramming, for example, to define accessors. But Ruby’s killer-app, Rails pushes this usage even further to provide a DSL for web development. See for yourself, I doubt you will find that Rails’s productivity claims are exaggerated.

For more information on metaprogramming and DSLs, I would recommend listening to the latest Rails podcast with Glenn Vanderburg and to check out Glenn’s blog, starting by this post. I also found Jose Antonio Ortega Ruiz’s blog, programmings musings to be a goldmine, see particularly: this post and follow the link to this good introduction to metaprogramming.

Io, Io, it’s off to work we go…

Wednesday, February 15th, 2006

First of all, sorry for the title of this post, I just could not resist!

For the last few days, I have been working on the coroutine code in Io. Coroutines are implemented in a system dependent way.

For Windows, Io uses the fiber API. This is nice and simple.

On Unix platforms where it is available, Io uses ucontext.h which is also nice and simple (although the makecontext function call has a bit of an odd signature, understandably).

On other Unix platforms things get very hairy. Io uses setjmp to save the current stack context, modifies the stack context and eventually, when the coroutine gets called, uses it with longjmp. The modification of the stack context cannot be done in a portable way, for the very least because different systems have different registers and stack frame formats.

For linux x86, for example, this involves:

  1. changing the instruction pointer register (EIP for a 32bit machine) to point to our coroutine start function
  2. allocate a stack frame for the coroutine start function call
  3. push the start function parameters on top of the stack
  4. have the stack pointer register (ESP for a 32 bit machine) point to this made up frame

Note that for linux, ucontext.h is probably a better choice (is it guaranteed to be there on recent kernels, I’d need to check).

Things are entirely different on OS X, where stack frames are more complex to setup. Good luck Steve!

On a much lighter note, I setup a frappr map of the Io community.

Io: small is beautiful

Thursday, February 9th, 2006

I have always enjoyed learning a new programming language, especially when the language in question opened my eyes to new idioms. Lisp had a profound impact on me. Prolog too. (I confess, I still have to learn Smalltalk – it would no doubt make this list). Recently I have been teaching myself Ruby. Ruby shares a lot with Lisp (so thinks Eric Kidd). It looked familiar enough very quickly. Ruby’s “principle of least surprise” works for me! While reading about Ruby I stumbled upon an interview of Yukihiro “Matz” Matsumoto, Ruby’s creator. When asked what languages he would recommend to learn, Matz answered Io and Haskell.

I do not know why I chose to have a look at Io rather than Haskell. What I know is that I really like the Io language. Io is beautifully simple. It might not appear so to a newcomer. I suppose this is due to the documentation lagging a bit behind a fast changing implementation.

Here are a list of places to check out if you are looking for information:

  • The Io Manual: great introduction
  • type-z wiki: another great introduction
  • Code samples: short but informative examples
  • irc channel: a very friendly and knowledgeable community, good place to get some help, discuss features… I have met some very interesting people there
  • Pipapo wiki: more advanced information

Have a look, you will be charmed!

Thanks to everyone on the IRC channel, I have learned so much on so many interesting concepts in so little time.