I’m sitting here at JAOO, waiting for the second day to start. The first presentation will be a keynote by Lars Bak about V8. It was a quite language heavy event yesterday too, with both Anders Hejlsberg and Erik Meijer keynoting about languages – plus there were introductions to both Fortress and Scala going on. And after the JVM language summit last week, I feel like the world is finally starting to notice the importance of programming languages.
So it seems only fitting that I’ve decided to go public with Ioke, the source code, what it is and where it’s going.
Ioke is a strongly typed, extremely dynamic, prototype based object oriented language. It’s homoiconic and got built in support for several kinds of macros. The languages that most closely influence Ioke is Io, Smalltalk, Self, Ruby and Lisp (Specifically Common Lisp).
The language is currently built on top of the JVM, but I’m currently considering compiling it down to JavaScript and run it on V8.
I have several goals with the language but the most specific one is to create a language that combines the things I like about Ruby and Lisp together. It turns out that Io already has many of the features I’m looking for, but in some cases doesn’t go far enough. I also wanted to have a language that is very well suited to express internal DSLs. I want to have a language that doesn’t get in my way, but also gives me loads of power to accomplish what I want. To that event I’ve designed a macro system that some people will probably find insane.
The current status of the implementation is that there isn’t any. I’m starting from scratch. I’ve already created two partial implementations to find the right way to implement the language, so with this blog post I’m starting the implementation from scratch. I know quite well what I want the language to look like and how it should work.
I’ve used Scala for the other two implementations but have decided to not do that for this implementation. The reason being one that Charles Nutter often talks about – that having to include the Scala runtime in the runtime for Ioke seems very inconvenient. So the implementation will initially use Java, but I’m aiming for the language to be self hosting as quickly as possible. That includes creating an Ioke Antlr backend, so it will take some time.
I’m going to post about Ioke quite regularly while I’m working on it, talking about design decisions and other things related to it. I will try to base me decisions in Ioke on what seems right, and not necessarily on the words chosen for representation in other language. I’ll try to talk about my reasoning behind choices like this.
And what about performance? Well, I know already that it will be atrocious. If you want to do scientific computing, maybe Ioke won’t be for you. The current design of the language will make it fairly hard to do any kinds of performance tunings, but I do have a plan for how to compile it down to bytecode at least. This still doesn’t mean it will perform extremely well, but my goals for Ioke specifically doesn’t include performance. I care about performance sometimes, but sometimes I don’t and Ioke is a tool I want to have for those cases where raw expressiveness power is what is most important.
You can follow the development in my git repository at http://github.com/olabini/ioke.
15 Comments, Comment or Ping
Just curious :
How do you go about implementing it (apart from choosing the method naming scheme ? )
do you write tests first ?
if you do what language do you write the tests in ? ioke ?
September 30th, 2008
With strongly typed you don’t mean statically typed, do you?
September 30th, 2008
Jean:
Well, that’s tricky. I’m planning on working mostly test first, but start out with a functional test-first process. I’ll make the implementation test itself as soon as the language is complete enough to run a simple test suite. Until then I’ll use JtestR to write the tests in.
Martin:
No, I mean strongly typed. It’s a dynamically typed language – which means it’s not statically typed.
September 30th, 2008
Your “hello world” example [1] looks exactly like Io source. What specifically is (not) in Io that prevents you from morphing it into what you need it to be?
[1]: http://github.com/olabini/ioke/tree/master/test/scripts/hello_world.ik
September 30th, 2008
Hope you can continue to keep up the motivation.
Personally I think the Io language has slowed down its development pace A LOT, it obviously is a lot of work to thrive a language through its evolution
September 30th, 2008
Steve Dekorte and I were talking about the possibility of making an IoLite that runs on the JS VMs. You interested in getting together to talk about it?
September 30th, 2008
Jason:
Well, you are exactly right except that it would actually have been a := instead of just an =. Of course this is the absolutely simplest case, and the divergence will be more obvious in the more complicated things. I have several reasons for doing my own language instead of building on top of Io, but I admit that Io is definitely the closest relative (that’s why I named it Ioke). Anyway, I’ll post something in the next few days about why I’m not going with Io for this.
Markus:
That might be true. I definitely understand that it’s extremely hard to continue working on a language implementation. And I really hope I’ll continue to be motivated to do it. =)
Rich:
Funny that you mention it. As I said in the post I’ve had serious thoughts about compiling Ioke to JS. It would be fun to get together and talk about something like IoLite, although it might be hard to organize since I’m currently in Sweden.
One thing to keep in mind about such an approach (which I find make the language less usable) is that JS doesn’t have threads. Of course, you can use the same model as Io uses and do green threads in the implementation of the language – or you could do CPS transformation. But it’s something to keep in mind.
September 30th, 2008
So what means “ioke”? Where’s this name come?
September 30th, 2008
We are both in SF so maybe when you come to SF for a talk you can ping us.
October 1st, 2008
To be pedantic, Io has coroutines which I would consider different from threads (they are cooperative and aren’t preemptive). This allows simpler concurrency at the cost of some memory when using multiple cores (processes are required for parallelism). To avoid confusion I should add that coroutines are more memory efficient for concurrency (not parallelism) since they use less memory than threads.
October 1st, 2008
> Ioke is a strongly typed […] prototype based […] language
Could you please elaborate a bit on the difference between a strongly typed and a weakly typed prototype based language?
October 1st, 2008
What about a programming language implementation tutorial?
Eg: small grammar, antlr, implementation….
I know that there are a lot of books, and pages, but somehow, for me its taking too much time and effort to grasp all the details of a programming language implementation. Personally I started up with antlr, parsers generators, but I stopped there. (and probably not only me is in this situation).
What I will do now, is to keep an eye on yoke to see what you are doing there and to understand it.
Probably you are a very busy person. But that kind of tutorial will help lots of people (my assumption).
I’m following your blog for a time, and the way you present/ explain things, will make the tutorial fast-learnable, and therefore a gold starting-point for other developers who are passionate about programming and programming languages.
(I can help you wrote it, I still dont know how, but Im offering my help, if you agree)
What do you say?
PS: this is my firs comment on your blog and I wannt to congrat you for the quality of the articles (ideas, insights, comments, explanations), and for the way they were wrote (very didactic, cool, understandable).
October 6th, 2008
Reply to “Ioke”