I’ve been up to a lot of stuff in the past few months. Related to programming there are two projects, one of them I’m still working on (and intend to do so for the forseeable future):

• generica, a small, simple & dirty lisp-like language interpreter implemented in ANSI C.
• and Fancy, a new object-oriented dynamic programming language, heavily inspired by Ruby, Smalltalk and Erlang. There’s also a website up, but far from finished: fancy-lang.org – Check it out if you like

So yeah, the latter project I started about 6 weeks ago but didn’t have the time to really work on it until about 3 weeks ago. Since then I’ve managed to implement quite a few features.
Here’s a small overview of features working in Fancy already:

• Class definitions
• Method definitions
• String, Integer, Double, Array, Hash (Hashmap), and Block (lambda function / closure) Literals
• Method and operator calls (sending messages to objects)
• Simple loops
• Support for closures (performance improvements are definately possible though )

There’s still lots of stuff missing, obviously. Mainly most of the standard library (I/O, Threading/Concurrency, Networking, etc…) will have to implemented as well as some runtime features I haven’t finished or started yet. But it’s getting along quite nicely. If anyone dares to try it out, I’d love to hear some feedback, especially hearing some opinions on the overall feel and semantics of the language would be nice. You can get the code on github (see the link above) and try to build it. Compiling instructions are in the README file. Fancy is licensed under the GNU LGPL.

I’m still excited to see where this is gonna go, for myself and possibly others as well. We’ll see.

I’ll probably post some more information on the language and its implementation some time soon. Need to go now.

You can check out the video at my blip.tv channel: http://bakkdoor.blip.tv/
Currently the video is being converted to flash video (.flv), so you might want to check out the .ogv video file here, if it’s not done yet: http://blip.tv/file/2804484

[Update:]
Video is available now. You can also watch it here:

Anyhow, I hope you like it and I’d like to hear some feedback.

Btw, the programm I’m debugging in the video is stupidvm, a small & stupid virtual machine I’ve started working on 2 weeks ago, written in C.
You can check out the code either on gitorious or github.

Feedback is, as always, welcome
I hope you like it.

Current progress:
Class & module definitions work correctly now, meaning that it now fully supports nearly all concepts that you find in Ruby. The main difference is, that in contrast to Ruby, Blocktalk does not have any real Keywords predefined, except for just a few including:

• def (for indicating method definitions)
• do & end (for codeblocks)
• self (the same as in Ruby & Smalltalk: reference to the current object)
• return (explicitly returning from withing the middle of a method)
• yield (same as in ruby: yielding to a given implicit block)
• Some literal syntax (not real Keywords, but somehow belongs into this category) for Arrays, Hashes, Codeblocks, Integers, Floats, Strings, Symbols, Characters and of course Assignment

That’s pretty much it, regarding predefined keywords in the language itself. Everything else relies on expressions like message passing (a.k.a. method calling) to objects, assignments and arithmetic. Even defining new modules or classes is done by sending a message to the Class or Module class-object (very similar to how it’s done in Smalltalk and how you can also do it in Ruby).

Here’s a small example of defining a class and a module:

Module >> :ModuleA do
  def method_a = do
    Console puts: "in ModuleA#method_a!"
  end
end
 
 
Module >> :ModuleB do
  def method_b = do
    Console puts: "in ModuleB#method_b!"
  end
end
 
Class >> :Place do
  def 1/>self from_city = do |city_name|
    # should do something useful here ...
    Place new
  end
 
  def coordinates = do
    # do some calculation here...
    return (Kernel rand)
  end
end
 
Class >> :Person do
  1/>self mixin: [ModuleA, ModuleB]
 
  # constructor with named params
  def initialize = do |name age: age city: city|
    @name = name
    @age = age
    @city = city
  end
 
  def go_to = do |place with: vehicle|
    ((place is_a?: Place) and: ((1/>self distance_to: place) < 10.5)) if_true {
      vehicle take: 1/>self to: place
    }
  end
 
  def place = do
    Place from_city: @city
  end
 
  def distance_to = do |place|
    (place is_a?: Place) if_true: {
      dist = ((1/>self place) coordinates) - (place coordinates)
      dist abs
    } if_false: {
      0.0
    }
  end
end
 
chris = Person new: "Christopher Bertels" age: 22 city: "Osnabrück"
city = Place from_city: "Berlin"
 
Console puts: "Distance from chris to city:"
Console puts: (chris distance_to: city)
 
# Person mixed in ModuleA & ModuleB:
chris method_a
chris method_b

I’m still tweaking a little here and there, but I think most of the standard language features are working now. Now I’ll try to come up with some more unique things. I do have a few ideas already, but I still need to see, if they really work out nice. Let’s see

But there’s a more important thing to consider here:
All the implementations out there currently are (mostly) written in another language. JRuby in Java, IronRuby in C#, MRI (default Ruby intepreter) in C and even Rubinius is written to great part in C++.
The reason is simple: Since you need some way to actually get your code running, you’ll need a host language to get the Ruby VM running on.

Now consider writing a native Ruby compiler in Ruby itself:
Once you’re able to bootstrap the compiler (meaning, to be able to compile it with itself), you’ve got a natively compiled executable, written in Ruby, where you don’t need any runtime/VM for. You could actually write a Ruby Interpreter / VM completely in Ruby itself, since you could also compile it with the native compiler. Additionally, making changes and understanding the source code of all these parts would be much easier for a normal Ruby programmer than any other system, since it’s all written in the language it’s targeting.
Now this would be awesome, wouldn’t it?
Any Ruby programmer could actually work on the language platform with the language itself. I think this would just be really cool.

So once the compiler would work well enough to actually compile quite large programms, it shouldn’t be too hard to get a Ruby Interpreter written in Ruby.

Of course, writing a language implementation in the language it’s implementing isn’t something new. Most Lisp implementations have been written in Lisp, the same goes for C & C++ compilers. In the case of Lisp, we have a dynamically typed language which gets compiled. And if you take a look at some performance benchmarks, you’ll see that there are Common Lisp implementations out there, that are really fast for a dynamic language (very well comparable to the speed of C!). This obviously takes some time, but it shows what can be possible.

Fortunately, the code has been online at GitHub for a while now here: http://github.com/vidarh/writing-a-compiler-in-ruby
Since I’ve always been interested in language design and how compilers work, I forked the project and started working on it as well. I’m still learning a lot, but the code is still small enough to actually understand it even if you haven’t done anything like that before. The blog posts by Vidar especially help alot here, since a great deal of how the code actually works is explained there.
More and more this is turning into a compiler for the Ruby language and I’m excited to see where this is going