Last week I wrote an initial roadmap that we want to follow for the upcoming Vala releases on our way towards guaranteed language stability. Today we’ve released Vala 0.2.0 as planned. Tarballs are available from the GNOME FTP servers. It’s mainly a bug fix release, however, it also got some new features like nested namespaces, static constructors, and GType-registered enums. We also have three new contributed bindings for GNOME Keyring, SDL, and libftdi, and the usual updates for existing bindings.
Great work, Jürg.
Since you are about to rewrite the parser, I would like to see a alternative style of python’s indentation instead of curly brackets for block of codes.
For example, if the first line for a file is //StyleIndent, then the whole file will be treated as Python indentation style.
I hate to type and read all the { }’s now a day…
Great! I love vala.
@ac:
I don’t agree.
Syntactic indentation is maybe the only thing I hate about python.
Moreover, I don’t think Vala syntax is good for pythonic indentation, as it is more verbose, sometimes requiring CR and tabs to make it more readable. This could lead to misinterpretations by the programmer and by the parser.
@ac
Writing a new parser doesn’t mean that we want to change the language. Supporting two fundamentally different syntax styles in the same language would probably cause more problems than it would solve. However, it wouldn’t be that difficult to write a parser for a new language with Python/Boo-like syntax and use libvala as a compiler library, if there is interest in that.
juergbi,
Ive been looking at doing that (boo language) for vala.
Main problem is you cant use lex/flex for block indentation as lex can only return one token per parsed value (EG you might need to return multiple dedents on a newline which lex cant do). Could do it by preprocessing the source of course prior to lex but that would make things slower…
If a hand written parser is going to be done for vala then it would make sense to do something similar for a boo language. Would be great if the parser you are going to write had a featureful parent class to allow other langs to reuse that code 🙂
Also would be ideal to have all the languages within vala so that valac can compile different src files in different langs (valac simply calls the right parser based on file extension of src file) – the only difference between the languages would be the lexer/parser so wont complicate things too much nor require too many changes. Implementing it externally via libvala would forego those advantages and be problematic too unless libvala was abi stable.
jamie
@jamie
There is very little code in the Vala parser that could be reused for a parser for a different language. Most of the code in the parser is closely tied to the syntax. Language-independent code parts are in the many other classes, which can be reused, of course.
Integrating the parser for a Boo-like language into libvala and valac would be fine, assuming it’s actively maintained. I assume you also want extended support for type inference, this will require enhancements to libvala but I don’t see any fundamental issues.