RailsWayCon coming up

It is less than a month to RailsWayCon in Berlin, so I thought I’d mention it here. This look like it will be a very nice conference. The dates are May 25 to May 27, in Berlin, Germany.

I will do two presentations and one keynote there. The presentations will be “JRuby Internals” and “Ioke for Ruby developers”. The keynote is called “Present and future of programming languages” and will feature my typical kind of ranting about programming languages.

Anyway. Hope to see you in Berlin! You can find more information here: http://it-republik.de/conferences/railswaycon.

Ioke geek night in London

I will hold a presentation about Ioke in London, Thursday 14th. This will be held at Skills Matters location. You can find more information, and sign up, here: http://skillsmatter.com/event/java-jee/ljc-meetup-346.

NRegex separated into its own project

If you’re interested in my regular expression engine for .NET, you can now download and build it from http://github.com/olabini/nregex. The files will shortly be removed from the Ioke source tree.

.NET and interface madness

The original Ioke implementation uses interfaces in place of classes when referring to collections. This is standard in the Java world, and wasn’t something I explicitly designed in, although it did make things very convenient in some cases, when I switched implementation strategies, or wanted to add ordering to to a dictionary. No references changed, just the pieces creating new instances. Very nice.

When I started the Ioke port to the CLR, I assumed that the collections work the same way in .NET, especially since there at first glance seem to be several interfaces for collections.

Boy was I wrong.

My first piece of unease came when I realized that there was no specific Set interface, so I ended up using ICollection instead. That works, but I use interfaces to capture intent, and in the specific case the intent to have a set was extremely important.

The next problem cropped up when I realized there was no unification of generic interfaces and non-generic interfaces. This is obviously not possible since the CLR uses reified generics, but I still hadn’t actually thought about it. This turned out to be extremely annoying in some cases – especially with regards to ordered collections. OrderedDictionary is more or less a counterpart of LinkedHashMap in Java – it keeps track of insertion order and will yield the entries in that order when iterating. This can be highly useful functionality. I wanted it for representing cells, like I do in the Java implementation. Problem is, cells is a collection that should be generic – but OrderedDictionary is not generic. Sigh. I could of course implement my own versions of these, but the point of a collections library is that I shouldn’t HAVE to do that.

The next item in the case against .NET happened when I started getting strange exceptions when I called ICollection.Add with a HashSet in that reference. The objects sent to Add shouldn’t have been any problem, but I still got (but only sometimes) exceptions saying my object was out of range, or something like that. I tried different things, but nothing solved it. At that point I noticed that HashSet<T> had two different implementations of Add. One regular, and one explicit ICollection.Add implementation. I couldn’t figure out if they were the same or not, but since it was listed separately, I thought they might be different. So I changed the original reference from ICollection<T> to HashSet<T> … And the error went away. I’m not sure if this is a bug in Mono, or .NET, or something else really weird, but that’s the behavior I saw.

And that brings up my main point. You can’t really use many of the interfaces in the .NET core library. Interfaces are about hiding implementation details and expressing intent – but when they don’t work, or are mismatched like they are in the .NET collections, this is impossible to do well. Bringing in explicit interface implementations that do different things depending on called with the interface as reference or not, only makes the situation even harder.

The story has a sad ending. I reverted to using explicit implementation classes for all references to collections. This sucks in many ways.

Some .NET reflections

I used to do .NET, when it was new. I’ve been away from it for several years though, so coming back to it feels like jumping in to a new environment. I’ve been using C# and F# for the new Ioke implementation, and during this time I’ve collected some thoughts and opinions. These are all framed in my regular use of Java, of course. And if this is obvious stuff to anyone else, please feel free to ignore me.

I won’t write everything in this post, though. I’ll split it up a bit. This is just the folio.

Incidentally, if you have seen tweets from me sounding pissed of, chances are good you will get explanations for it from these posts. At the moment I will write three posts: Opinions on F#, Opinions on C# and .NET, and .NET and interface madness. That is what I have planned right now, at least.

Ioke for the CLR released

The last two weeks I’ve been furiously coding away to be able to do this. And I’m finally at the goal. I am very happy to announce that the first release of Ioke for the CLR is finished. It runs on both Mono and .NET.

Ioke is a language that is designed to be as expressive as possible. It is a dynamic language targeted at several virtual machines. It’s been designed from scratch to be a highly flexible general purpose language. It is a prototype-based programming language that is inspired by Io, Smalltalk, Lisp and Ruby.

Homepage: http://ioke.org
Download: http://ioke.org/download.html
Programming guide: http://ioke.org/wiki/index.php/Guide
Wiki: http://ioke.org/wiki

Ioke E ikc is the first release of the ikc Ioke machine. The ikc machine is implemented in C# and F# and run’s on Mono and .NET. It includes all the features of Ioke E ikj, except for Java integration. Integration with .NET types will come in another release.


  • Expressiveness first
  • Strong, dynamic typing
  • Prototype based object orientation
  • Homoiconic language
  • Simple syntax
  • Powerful macro facilities
  • Condition system
  • Aspects
  • Runs on both the JVM and the CLR
  • Developed using TDD
  • Documentation system that combines documentation with specs

There are several interesting pieces in ikc. Among them I can mention a new regular expression engine (called NRegex), a port of many parts of gnu.math, providing arbitrary precision math, and also an implementation of BigDecimal in C#.

Ioke Geek night at ThoughtWorks Bangalore

Tomorrow (Tuesday) evening, at 6pm, I will give a presentation about Ioke, at the ThoughtWorks office in Bangalore. This is an open event. More information and registration here: http://www.thoughtworker.com/events/geeknight-ola-bini.

Ioke E released

After a slightly longer development cycle then the last time, I am finally happy to announce that Ioke E has been released.

Ioke is a language that is designed to be as expressive as possible. It is a dynamic language targeted at the Java Virtual Machine. It’s been designed from scratch to be a highly flexible general purpose language. It is a prototype-based programming language that is inspired by Io, Smalltalk, Lisp and Ruby.

Homepage: http://ioke.org
Download: http://ioke.org/download.html
Programming guide: http://ioke.org/wiki/index.php/Guide
Wiki: http://ioke.org/wiki

Ioke E is the third release of Ioke. It includes many new features from Ioke S, among them full support for Java integration (including implementing interfaces and extending classes), many new methods in the core libraries, IOpt, TextScanner, BlankSlate, better support for regexp interpolation and escapes in regexps, support for Unicode analysis and much more.

Ioke E also includes a large amount of bug fixes.


  • Expressiveness first
  • Strong, dynamic typing
  • Prototype based object orientation
  • Homoiconic language
  • Simple syntax
  • Powerful macro facilities
  • Condition system
  • Aspects
  • Java integration
  • Developed using TDD
  • Documentation system that combines documentation with specs
  • Wedded to the JVM

The many things added in Ioke E could not have been done without the support of several contributors. I would like to call out and thank:
T W <twellman@gmail.com>
Sam Aaron <samaaron@gmail.com>
Carlos Villela <cv@lixo.org>
Brian Guthrie <btguthrie@gmail.com>
Martin Elwin <elvvin@gmail.com>
Felipe Rodrigues de Almeida <felipero@gmail.com>
Wes Oldenbeuving <narnach@gmail.com>
Martin Dobmeier <martin.dobmeier@googlemail.com>
Victor Hugo Borja <vic.borja@gmail.com>
Bragi Ragnarson <bragi@ragnarson.com>
Petrik de Heus

Laziness in Ioke

Since all the rage in blog posts at the moment is laziness, I thought I’d take a look at how something can be lazy in Ioke. There are several ways of doing this, but most of them are really easy. I haven’t decided exactly how the implementation in core should look like, but it would probably be something like the following.

Basically, for laziness in a dynamic language you want something that lazily evaluates itself when requested the first time, and after that always return that value. Something like this:

foo = Origin mimic
foo bar = lazy("laziness has run!" println. 42)
"helo" println
foo bar println
foo bar println

Here we create a lazy values that returns 42, and prints something to prove what is happening. The lazy-method contains the magic. Any code could be submitted here. In this case the code can lexically close over variables outside, if wanted.

How would we implement “lazy” then? Something like this would suffice:

DefaultBehavior lazy = dmacro(
  laziness = fnx(
    result = code evaluateOn(call ground)
    cell(:laziness) become!(result)

This code creates a lexical block and returns it. That block is a closure around the argument code. When called, it will evaluate that code, and then change itself to become that result value. Most of the magic here is really in the "become!" operation. And that is how simple it is. Since Ioke tries to make things representation independent, this implementation of lazy works in basically all cases.

IKanServe – an Ioke web framework

The last few days I’ve cobbled together IKanServe, which could be called a web framework, if you’re really generous about the meaning of the words. It doesn’t really do that much right now. But it does allow you to serve dynamic web pages using Ioke.

Much of the hard parts in the Ioke servlet was totally cribbed from Nick Sieger’s JRuby-rack, which is a very well-engineered project.

IKanServe is basically three different parts. First and most importantly, it’s an IokeServlet, that takes care of starting runtimes and pooling them. The second part is the Ioke parts of dispatching, that will turn headers and parameters into a dict, and then find matching actions and dispatch them. The third part is a very small builder library that lets you create HTML with Ioke code. In fact, the code for the html builder could be quite interesting, so let’s start with that. It’s very small, promise!

IKanServe HtmlBuilder = BlankSlate create(fn(bs,
    bs pass = method(+args, +:attrs,
      args "<%s%:[ %s=\"%s\"%]>%[%s%]</%s>\n" format(
        currentMessage name, attrs, args, currentMessage name))))

As you can see, we use a blank_slate library, that is part of the standard library of Ioke. If you’re familiar with Ruby, you know what a blank slate is. Ioke’s blank slate is a bit more blank than the Ruby equivalent, though. To create a blank slate, we call the create method, and then send in a lexical block where we can set up anything we want to have on the blank slate. After create is finished, it will be impossible to add new stuff to the blank slate, so this is the only place we can do that. What we do here is to add a “pass” method. Pass is mostly the same as method_missing in Ruby. That method will create a tag from the method name, add all keyword arguments as attributes, then add all the content inside the tag and finally close the tag. The funky looking syntax in the Text literal is mostly the same as the % or sprintf methods in Ruby.

There is some subtle things going on in this method, but to go into them would derail this whole post. Before abandoning the HTML stuff, you might want to know how to use it. This is how:

h = IKanServe HtmlBuilder
title = "I kan serve HTML!"
h html(
  h head(h title(title)),
  h body(
    h h1(
      style: "font-size: 1.5em",
      "Isn't this cool?"

HtmlBuilder doesn’t have any state, so you just use it immediately. I alias it as “h” to make it easier on the eyes. That means that every call to the “h” object will return html. That’s how I can differentiate between creating the tag “title” and referring to the variable “title”. This is very easy stuff, but it seems to work well for smaller cases.

OK. Let’s get back to the rest of IKanServe. What do you need to use it? In your WEB-INF, you need to have three files in the “lib” directory – namely “ioke.jar”, “ioke-lib.jar” and “ikanserve.jar”. Since Ioke is inbetween releases you will have to build these yourselves, but it’s pretty simple. You can build the first two using the target “jar-lib” in the Ioke source. The third can be created by checking out ikanserve from Github: http://github.com/olabini/ikanserve, and then building it with ant.

Once you have those in your WEB-INF, you also need a web.xml file. It should look something like this:

<?xml version="1.0" encoding="utf-8"?>
  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"





Nothing spectacular, just set up the number of runtimes, the servlet and a servlet context listener.

And that’s it. Now you can build a war file and it will be ready to serve. Of course, if you deploy it and try to go to any URL, you will get a message that says: “Couldn’t find any action corresponding to your request. Sorry!”. That’s the default 404 action.

To actually create some code that does something, you need to create a file called iks_application.ik. This file should be places in WEB-INF/classes. Any other Ioke files you want to use should be on the classpath, and you can just use “use” to load those files. What can you do in IKanServe then? Well, basically you can bind actions to urls. Right now there is only one way to bind urls, and that is with regular expressions. A typical small action can be bound like this:

IKanServe actionForPath(#r[^/bar],
  method("you requested this: #{request pathInfo}"))

Here we bind any URL that starts with /bar to the method sent in. At the moment you have access to a request object, and the return value of the method will be rendered as the result. And that’s basically it. As mentioned above, it’s not so much a framework as the initial skeleton for one – but it still works quite well.

If you want to try this out in the easiest way possible, you can do “ant example-app” in the ikanserve source tree, then do “cd jetty” and finally do “java -jar start.jar”. This will build and deploy an example application and then start a Jetty instance to serve it. Go to localhost:8080 and try /foo, /bar or any other URL, and see it in action. You can see the code for this small app in web/WEB-INF/classes/iks_application.ik.

And that’s all for this time. Have fun.