Freya says Hi!
Hello World!
This blog is dedicated to the Freya Programming Language, a new object oriented language specially designed for running on the .NET Framework, version 2.0 and higher, when available.
In the next few days, I'll post more information about Freya features and, mainly, about its ongoing implementation. I will appreciate any comments, suggestions and proposals.
Freya is a join effort by Moebius Ootics (www.moebiusootics.com) and Intuitive Sight, a.k.a IntSight (www.intsight.com), my own company.
Best regards, and keep in touch!
Ian Marteens
posted by Ian at 4:07 PM
3 comments
3 Comments:
It should, by the very nature of the .NET framework. We are not testing the compiler in Mono, at this stage, but our compiler is 100% pure managed code (no native DLLs, no COM classes)and it should port without problems.
Sounds promising. When will a download be available?
A month from now, I think. It would be a kind of alpha version: the compiler is very robust and stable. It won't include support for CodeDOM or visual designers in this first release, but support for these things is on the way.
Things I must implement before the release:
1- Highest priority: DLLImport for dealing with native code. It shouldn't be a great deal, it's just that I didn't realize I needed it.
2- Nasty little but required feature: partial classes.
3- Important: this version is still "LINQ-less".
Why, then, a cut and a release right now? Easy: it already works as a language with very good code generation. I have plans to put some emphasis on this point: Freya as a language you could use to implement those critical parts in a bigger application. It could provide support for multi-module development (VS2k5 doesn't have it right now: you must use CSC if you want modules).
It may seems strange to hear there's room for an optimizing compiler in .NET, despite the excelent JIT compiler. However, it's true: just see what happens when iterating a generic List[X]. All compilers, including C#'s, applies the iteration pattern, and calls List[X].GetEnumerator to retrieve a structure implementing MoveNext and Current. And, of course, this is a lot better than using IEnumerable[X] directly. However, there's a better way: treat the List[X] as you would treat a normal array. I mean: translate the iteration using the same pattern as for an array. It's way faster.
Of course, there are some issues to consider: there are some subtle changes in semantics if you compare both solutions. So, the compiler must ask the programmer what does he/she prefer. And there are a lot of cases like this one. Think of field-based properties, for instance: I'm inlining access to these properties as long as they are not declared virtual. The implicit fields are declared internal, instead of private, so other classes inside the same assembly could benefit from the direct access to the underlying field.
Post a Comment
<< Home