I haven’t posted here in a long time. Mostly due to working on Fancy a lot. Just wanted to post a video of a talk I gave in June at warpzone.ms hackerspace in Münster (Germany).

The talk is in German, but it might be of interest to some people, so here it is:

Fancy Talk 12.06.2010 @ Warpzone.ms from Christopher Bertels on Vimeo.

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.

gem sources -a http://gems.github.com (if not done yet)
sudo gem install bakkdoor-blocktalk

You can then simply run blocktalk from the shell via

blocktalk sourcefile.bt

To look at some debug information (e.g. the AST, the generated ruby code etc.) type:

blocktalk sourcefile.bt –debug
or
blocktalk sourcefile.bt –ruby (to only show the generated ruby code)

Feel free to play around with it, check out the examples in the examples folder, if you want to get a start.
Would love to hear some feedback from anyone who’s interested, since this is my first attempt to language design

str = ("Hello, world!" upcase) gsub: "," with: ":"

Now you can do something like this:

str = "Hello, world!" upcase gsub: "," with: ":"

Which is equivalent to this ruby code:

str = "Hello, world!".upcase.gsub(",", ":")

Much nicer, if you ask me. Of course you can chain as many methods as you want, even with each method taking a codeblock, if you want to (as it is possible in ruby as well).
So now that I’ve got the most important things done, I’ll try to focus a little more on refactoring, working on the standard library (adding more classes & methods) and thinking about some more unique, new features for the language

Basically, it’s just a simple portscanner.

System require: "socket"
 
host = "localhost"
 
(ARGV at: 0) if {
  host = (ARGV at: 0)
}
 
open_ports = []
 
1 upto: 1024 do |port|
  Thread new {
    try{
      t = TCPSocket new: host port: port
      open_ports << port
 
      s = Socket getnameinfo: ["AF_INET", port, host]
      Console puts: ("\nPort #{port} (#{s[1]})" + " is open.")
 
      catch{
        Console print: "."
      }
 
      ensure{
        t if { t close }
      }
    }
  }
end
 
Console puts
Console puts: "Open ports on #{host} are:"
Console puts: (open_ports join: ", ")

So yeah, this is actually working. Now I’ve basically have most of the language features done that I had in mind first. Next to come are probably some performance optimizations as well as some more unique features, I still have to come up with. We’ll see

Update:
I’ve added Threading to the code, this speeds up the process a little

For now, the interpreter is able to understand & execute methodcalls on objects, anonymous methods (blocks & procs in ruby) and some other minor stuff.

Heres a small example, that actually works now:

y = { |x|
  Console puts: x
  Console puts: (x * x)
}
y call: 10
 
m = { |x y|
  Console puts: ((x upcase) * y)
}
m call: "cool " y: 10
 
square = { |y|
  y * y
}
cubic = {|x| (x * x) * x}
 
3 times do |i|
  Console puts: i
end
 
foo = {
  3 times { |i| Console puts: (square call: i) }
}
 
Console puts: "--"
 
foo call
 
10 times &foo

This basically is equivalent to the following ruby code:

y = Proc.new{|x| Console.puts(x);Console.puts(x.*(x))}
y.call(10)
 
m = Proc.new{|x,y| Console.puts(x.upcase().*(y))}
m.call("cool ", 10)
 
square = Proc.new{|y| y.*(y)}
cubic = Proc.new{|x| x.*(x).*(x)}
 
3.times(&Proc.new{|i| Console.puts(i)})
 
foo = Proc.new{3.times(&Proc.new{|i| Console.puts(square.call(i))})}
 
Console.puts("--")
 
foo.call()
 
10.times(&foo)

Now, to make this clear: The ruby code above is what the current interpreter actually executes. The way I’ve implemented it for now (and for simplicity only – just to get something working first) is, that it simply parses the blockd code and translates it into equivalent ruby code, which then gets executed via eval in ruby.
Now I know, this isn’t the best way to do it, for several reasons:
Normally, an interpreter executes the code it gets fed directly, expression for expression, as this is also the case for ruby. If you have an syntax error within the code that is evaluated, the interpreter usually notices this only at the moment it reaches that part of the code and tries to evaluate it. This isn’t the case for the current interpreter I wrote here. The reason I chose to do it this way, was that I wanted to get something working as possible. I do want to change it though later on, so that each expression gets executed on the fly, once it is parsed.

So for now, i evaluate the parsetree, and each expression node gets turned into a string of equivalent ruby code, that then gets saved in a global list (within a class called Evaluator). When the parser has done it’s job and all the values (strings of ruby code) of all expression nodes have been accumulated, i simply run ruby’s eval on it and at that point do the actual evaluation (and possibly get semantic errors here – like missing variables etc.).

I still need to implement some stuff regarding classes & modules, but I’m quite happy for now, since it wasn’t so hard as I had expected before. Once I have everything working, I’ll start to actually rewrite the parser in a way, that it evaluates & executes code on the fly, expression per expression and not all of them at once at the end. This should also improve performance, which is obviously another downside of my current approach, since I have to wait for all expressions being parsed & evaluated to appropriate ruby code first, before even beginning the actual evaluation process…

For anyone, who is interested, here is a simple benchmark of the code above:

The blockd version (executed with my current interpreter):

real 0m0.264s
user 0m0.184s
sys 0m0.072s

The ruby version of the equivalent code (generated by my parser):

real 0m0.021s
user 0m0.008s
sys 0m0.008s

As you can see, there’s quite a performance overhead. Although not really noticeable by a viewer, the numbers tell the story. So I expect quite an improvement in performance, once I’ll start rewriting the interpreter in the way I’ve mentioned above. Still cool though, if you ask me