Saffire: A dive into a new language

Confused by Perl? Bored by Python? Ruby too 2011? What’s the alternative? PHP? Come on!  Well, seek no further since here is the next language for at least the coming decade: Saffire!

Well, I hope you took the first part not too seriously :). I wouldn’t too. Saffire is just an idea still in the heads of a few people. There isn’t a interpreter yet, there isn’t a parser yet, heck, there isn’t even a language specification yet. We even aren’t sure about the name neither. So what IS Saffire then?

The idea

The idea of creating a new language is born out the fact I wanted to learn more about Flex/Bison. You know, for fun. (actually just lexing and parsing, but I’ve had my mind set on the Flex/Bison combo to achieve that). Very quickly I decided to go on and try to create a parser that could actually parse PHP files, but when looking for information (actually, reading up on the Zend Language Parser), I though: wouldn’t it be fun to have a language that takes all the good things from Python, Ruby and PHP, and mix them together? So from there, Saffire was born. 2 hours later, I had a github account, some examples on how the language would look like and some people wanted to join the project!

Why Saffire?

Saffire is a hybrid between the dutch and english words for sapphire (saffier). It’s in line with the Perl and Ruby gemstone naming and even though for now it’s still a working title, it seems that nobody objects to the name. But this does not mean that Saffire is just a dialect from Ruby. Actually, it will be a big blend of mostly Python and PHP as far as it seems. Yay. we’re half way there..

Saffire selling points

So why would you want to use Saffire? These are a few of the things we want to implement:

Objects We hope one of the strongest points of saffire is the fact that everything is an object. That includes scalars like numerical values, and strings like "foobar". This means, it’s completely valid to do 10.add(1); Here we use 10 as numerical object, together with all kind of methods you expect from numericals.

No functions

There will be no functions. Only methods. This means that global functions are not available, and everything will *be done through methods. We still are worried about closure/lambda/anonymous functions, which we definitely want to *support.

UTF8 out of the box

Every string object will be UTF-8. This means that a “κόσμε”.len() will return a length of 5, since len() will return 5 characters. It is still possible to get the bytes, in case you need them. ”κόσμε”.bytes().len() would return 12, since the string consists of 12 bytes.

Operator overloading

Operator overloading allows us to create methods to overload operators like +, - etc. This means the following code  makes much more sense:

$mixed_color = Color("yellow") + Color("blue");

$mixed_color would be a Color object with value “green”;

Method overloading (maybe)

Method overloading would allow us to have multiple methods with the same name, but with different argument lists.

class Color {
  method Mix(Color $color) {
  }
  method Mix(String $color) {
  }
  method Mix(Integer $pmsColor) {
  }
}

There will be much other stuff and some of these will or will not be present in the final language spec.

What makes Saffire different?

I think the whole idea is not so much that Saffire will do things differently that others, but we try to combine the strengths of all languages into one. Our idea is not world domination (and if it was, we’re not going to tell you in advance anyway), nor aren’t we building a language because others languages suck and are hard to work with. We just want to stick some heads together and see: if we take all the good things from languages, will it blend? And if so, how would it look like?

Personally, I think the language will be mostly like Python, but with heavy PHP influences. We will start with an system that parses (and optimizes) a bytecode. This bytecode will then be interpreted by another system. However, it would be nice if we will be able to implement a JIT-compiler, or even a full blown compiler to native code.

Looks like fun, how can I join?

At the moment, one of the most important things is setting up a language specification. In here we pretty much define the rules of the language and what we can (and cannot) do. When this is done, we can actually try and think about implementing this correctly. Off course, we are pretty much 10-15 years behind other languages, but as a result, we might be able to avoid some of the pitfalls that others have stepped in to in those years.

We will need programmers, preferably with more understanding compiler theory than we do (:P), but anyone who wants to join in are more than welcome. Even if you don’t program in C, we still need people to setup the language specs!

For now, we have the source up and running on https://github.com/saffire/saffire, and you are always welcome to join us on IRC freenode in channel #saffire.