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.
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.
Features:
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#.
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.
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.
Features:
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
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( [code] laziness = fnx( result = code evaluateOn(call ground) cell(:laziness) become!(result) 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.
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!
use("blank_slate") 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"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<context-param>
<param-name>ioke.max.runtimes</param-name>
<param-value>2</param-value>
</context-param>
<context-param>
<param-name>ioke.min.runtimes</param-name>
<param-value>1</param-value>
</context-param>
<servlet>
<servlet-name>IokeServlet</servlet-name>
<servlet-class>ioke.lang.ext.ikanserve.IokeServlet</servlet-class>
<load-on-startup/>
</servlet>
<servlet-mapping>
<servlet-name>IokeServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<listener>
<listener-class>ioke.lang.ext.ikanserve.IokeServletContextListener</listener-class>
</listener>
</web-app>
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.
In one and a half week, QCon London is coming up. That will be a week of great fun, and I definitely recommend it to anyone who has the possibility to be there. I have the highest respect for Trifork and InfoQ who are organizing the QCon conferences, and I’m definitely looking forward to it.
This year I am actually not speaking at the conference itself. Instead I’m hosting a track where other people speak. My track is called “Emerging Languages in the Enterprise” and I’ve managed to convince some amazing people to show up and talk there. To be specific, my speakers are: Jonas Boner, Michael Foord, Attila Szegedi, Rich Hickey and Martin Fowler. So, if you are interested in languages, be there; it will be a blast.
ThoughtWorks UK have a tradition to organize geek nights around QCon, and this time is no exception. On the evening March 10th (that is a Tuesday) I will be talking about how to create a JVM language. I will use Ioke for most examples, but will also contrast with details from JRuby. The presentation will be quite audience controlled, so exactly what will be presented is not determined. But it should give people a good grounding in Ioke, at least. More information here. Hope to see you there!
This Monday I took a trip to Amsterdam to attend and present at Amsterdam.rb. TTY, the company hosting this months meeting, had managed to get a pretty interesting lineup, and about 70 people turned up (in fact, that was the limit, so it might be possible to get more people).
This was my first time in Amsterdam, but due to me being really, really sick, I didn’t get to see much of the city. I did manage to spend a few hours with Sam Aaron and his Haskell friends, discussing programming languages and Ioke specifically. Much fun.
There were six sessions planned, but since the schedule was busted from the beginning, the TTY talk on quality had to be removed (which is a shame – I was interested in what it would be about).
The first presentation was a discussion about a tool that could convert UML and YAML description files into scaffolding with internal associations. The main goal for the tool seemed to be to really rapidly get an application started, but the workflow goes totally against the way I generally write Rails apps, so I had a hard time seeing any utility for myself.
After that, Martijn van Excel gave a presentation about OpenStreetMap. I found this extremely interesting. The project seems to be the wikipedia equivalent of maps, which means that areas that Google aren’t interested in mapping will still get mapped in OSM. An example Martijn displayed was a large city in the Philippines, where Google really didn’t have much information, while OSM was extremely detailed. After some discussions and questions, it does seem that OSM has the same drawbacks as wikipedia – spurious updates, trust issues and so on, but I didn’t get the feeling that OSM had implemented the same kind of verification structures that wikipedia uses – at least not yet. All in all a cool project, though. Will definitely consider it if I ever need to do map-based mashups. The lack of geocoding might be a problem, of course.
After Martijns presentation there was a break, and then it was my turn to talk about Ioke. All in all, I spent way to much time explaining some intricacies of the syntax, which meant I didn’t have enough time to talk about the really important stuff – things like macros and the testing and documentation tools. I need to reconsider how to present the material without getting bogged down with details that doesn’t matter as much. All in all I’m still happy about it, though. You can download my slides at: http://ioke.org/presentations/Amsterdam.rb.pdf.
After my talk, Ninh Bui and Hongli Lai from Phusion talked about how they do design by contract. It was a very polished presentation, and I liked the way they did it – but I still felt that I didn’t grasp exactly how they applied DbC. I would have liked to have a long discussion with them about it, since the presentation gave the impression that the main way they did DbC was by duplicating the contracts in comments, in code and in tests. Interesting discussion on how DbC interacts with LSP (Liskov’s Substitution Principle). Once I realized it was isomorphic to the way bounded generics work in parametric polymorphism, it became much simpler to get my head around.
The final talk was about RubyCocoa. At that point my fever had started to fry my brain, so I didn’t really get much out of that talk.
All in all, a great time. Met many interesting people and had some good discussions. The Amsterdam hackers are obviously very cool and I hope I can get back there sooner or later.
There is some photos from the event here: http://amsterdamrbfebruari09hostedbytty.shutterfly.com/.
Monday evening I’ll be in Amsterdam, talking about Ioke to Amsterdam.rb, inbetween some other presentations. Seeing as this is going to be the first public presentation about Ioke, I’m absolutely thrilled. It’s going to be great fun. I still haven’t decided exactly how to present Ioke, but I think it’s going to be eased by this being a Ruby crowd.
As far as I understand, the evening is actually fully booked, so there is no more space for people to come. But hopefully everyone in Amsterdam who is interested in Ioke (all three of you? =) will be there. The presentation will be at TTY’s offices in Amsterdam, from 19. It seems my presentation will be from 20:35.
Hope to see you there. This might be an historic event! =)
I generally get lots of different kinds of reactions from people when showing them Ioke. A very common misconception about the language is that it is “just another dialect of Lisp”. That is a quite easy mistake to make, since I’ve borrowed heavily from the things I like about Lisp. But there are also several things that make Ioke fundamentally different. Ioke is Lisp turned inside out and skewed a bit.
First we have the syntax. Ioke has syntax inspired by Ruby and Self, but includes some variations that come from Common Lisp too. The main difference between how Ruby and Ioke handles syntax is that Ioke will transform everything down to the same message passing idiom. Most of the syntax is in the form of operators, which don’t get any special handling by the parser at all. But the syntax is still there, and it is also deeper embedded compared to how Lisp generally does it. Ioke acknowledges the existence of different kind of literals – and allow you to override and handle them differently if you want. One of the examples in the distribution is a small parser combinator library. It allows you to use regular text and number literals, but in the context of the parser those literals will return new parser for their type.
Common Lisp can play these syntactic games with reader macros, but it is generally not done. Ioke embraces the use of syntax to improve readability and the creation of nice DSLs.
Of course, any Lisp guy will tell you that syntax has been tried – but programmers preferred S-expressions. The latest example of this is Dylan. But I’ll have to admit that if you look at the Dylan syntax, you understand why the programmers didn’t feel like bothering with it. It’s one thing to try syntax by just adding some very clumsy Algol-derivation. It is another thing entirely to actually focus on syntax.
That said, Ioke is homoiconic, and translates to a structure that could easily be represented as cons cells. It doesn’t, though, since the message chain abstraction works better.
The other thing that really makes Ioke different from Lisp – and also a reason that would make infix S-expressions extremely impractical – is that Ioke is fundamentally object oriented based on a message passing idiom. In a lisp, all function calls are evaluated in the context of the current package (in Common Lisp). You can get different behavior if the function you call is in fact a generic method, but in reality you’re still talking about one method. If you want to chain method calls together, you have to turn them inside out. That doesn’t lend itself well to a message passing paradigm where there is an explicit receiver for everything.
Ioke in contrast have the message passing model at its core. Any evaluation in Ioke is message send to some receiver. In that model, you really need to make it easy to chain messages in some way. And that’s why S-expressions would never work well for Ioke. S-expressions fundamentally doesn’t use the concept of a receiver at all.
All the other differences in Ioke versus any Lisp could be chalked down to minor dialectical differences, but the two biggies are the above. Ioke is not a Lisp. It’s heavily inspired by Lisp, but it’s fundamentally different from it.
|
I am a software developer working for Centro de AutonomÃa Digital, mainly with privacy, security and cryptography issues. I have worked on many different things in my life, including programming language design and implementation, security, privacy and cryptography, artificial intelligence and more. |
|
Quito |