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 numerics.
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.
Do you know Scala?
Will it be compiled or interpreted?
The first part of your post makes me very cautious. Compiler and language design are not small accomplishments. Reading ‘I wanted to learn about lexers so decided to create a language’ sounds as ambitious as ‘I bought a piano, lets compose a symphony’.
But good luck, php is over its peak, there is room for something new and shiny.
Writing a language isn’t hard, but writing a good language is VERY hard. I’m not really agreeing with your analogy though: every symphony ultimately starts with somebody buying a piano :). For instance, writing an OS is not an easy task to do, but in the end I’m very glad I took the time to gain the knowledge on writing one (with all its complexities) and the practical conquests and failures that makes you want to swing your computer out of the window.
As your question: We are initially aiming for a pure interpreted VM with our own bytecode (largely based on the java and python bytecodes). There were some idea’s about using LLVM but I’m worried this will be a very hard task to implement, plus we ultimately will need the control over our bytecode to start with, at which time LLVM will be more of a drag than it will benefit us. In a later stadium we want to add either a JIT implementation and later on we might even consider a compiler (or an intermediate that for instance outputs java or python bytecode). It’s still very open at this moment (remember it’s just 4 weeks old, compared to the 15+ years of most other languages). Will we succeed? I don’t know, but I agree with you that there is still room for new languages that runs the web, and every symphony starts with a first note in the end :)