Sign in to follow this  
  • entries
  • comments
  • views

Part II: Choosing a language

Sign in to follow this  


Having chosen a graphics engine I have now decided on what language I wish to use. Part of the many benefits of developing on .NET or Mono is the ability to defer the language choice. Because of the types of games and simulations I wish to make, the language I want has to be flexible, well suited to abstraction and strongly mathematical. This immediately eliminates much of the .NET languages, including C#. Now, C# 3.0 is better than ever with many decades old modern features but still only seems to have done them half-heartedly.

The language I chose was F#. On top of Nemerle. What does this mean? I do not know software engineering nor do I have the time to learn it. So I use something I am more comfortable with, abstract maths as a crutch to help make things go smoothly. Most of the code will be written in F# with Nemerle used to implement the framework or more specifically, the platform. First on F#.

F# is a powerful, succinct, functional, well abstracted language that is very good at large data manipulation and handling complex data-structures. Well suited to doing mathematical heavy lifting. F# is also at least as fast as C# on average (faster on some things, slower at a few). F# is also a well maintained and updated language and remains a priority for the developer(s) who works on it. Next.

Nemerle is also a succinct, functional, powerful hygenic meta-capable language. It is also a language designed with much insight and foresight. However, although it is still being actively updated it is not improving at a very encouraging rate. The language has sort of taken a backseat to other projects for the developers. The core of the language is well founded. However, venturing far outside that core is risky as the edges of the language are still unstable. Nonetheless it remains a powerful well thought out language.

Because of what I plan to do and how I plan to do it, I need as a base a language that is very close to its own specification. As a language which exposes its entire syntax tree, Nemerle fits that bill quite well. I plan to use it to create an environment where I can easily explore and implement my ideas, with natural self documenting code. As stated, most of the programming - data structures and algorithims - shall be done in F#. Nemerle will be used to tie things together since it can be pruned and easily adjusted to be more like one prefers. Including making it operate seamlessly with F#. I think. I plan to leverage and mainly use Nemerle meta-capabilites to help more easily implement my "nonstandard" approach.

Oh yes. the basic structure of the engine is a category.
Sign in to follow this  


Recommended Comments

F# has metaprogramming facilities, not as flexible as nemerle but it does have one advantage over nemerle's macros (until they implement it) and that is some support for multi-staging at runtime with combination of quotations and LINQ i.e. online partial evaluation (runtime specialization) declaratively which can be more useful than purely compile-time metaprogramming.

If your not sure what it is imagine bascially taking a generic algorithm/function where you have unknown variables at compile-time but you know a more specialized optimal version for specific cases. What you can do is multi-stage it for when varibles are known at runtime and it will always use the more optimal version for those cases.

Of course you can do this using virtually any .NET language via lightweight code generation (LCG) using reflection with DynamicMethod but this method is quite low-level and it's not declarative and the language is not the same language used (or subset) to write it, apparently LINQ uses LCG to optimize expressions so if you use quotations with LINQ you get declarative runtime specialization for free.

There is one slight downfall with this method in F# as compared to properly implementated runtime multi-staging (as is done with MetaOCaml) which is a slight overhead with using DynamicMethod but it's not so bad so long as whats actually being done out weights the cost of DynmamicMethod.

Anyways you might want to think about whether you really need the full power of nemerle macros and extending syntax or whether F#'s quotations & writing combinator libraries is enough for your needs.

Share this comment

Link to comment
Thanks snk_kid. As usual you information is not only useful but well explained.

Im using Nemerle for two reasons mainly. The first and much more important reason is that it is very easy to transform the language and the second is for any compile time optimizations that may be made. The idea is that I can be more efficient if the language is close to the type of thinking and approaches I plan on using. F# is already close but still not enough.

F#'s approach to meta-programming is conservative and so it is more complicated to do things related to transformation that would be trivial in Nemerle. But since currently F# is the more stable and maintained project I would ideally want most of my code to be in that language and will do any compile time stuff with it using combinators as you suggest. Also multi-staging looks cool but I cannot off-head know whether I will be doing anything which will offset any DynamicMethod inefficiencies.

I no longer think that I will be exposing any Nemerle Types, in fact Ill probably be more likely to send types down from F# since its type system is much more robust. Where possible Ill use quotations and comprehensions to get syntax close to what I want but only where it is simple. Otherwise I'll use of Nemerle. the idea is that the F# power work feeds the Nemerle specification/definitions. Thanks for the info.

Nemerle <- F#

Share this comment

Link to comment
Seems like Nemerle already does multistaging or something very much like it. One thing it also does is having certain macros be definable to operate at specific execution stages when dealing with types - whether applicable on inherited , typed etc info stage.

It also does multistaging in the conventional sense via partially evaluated functions in macros. It doesnt rely on LINQ to generate code and is still the same language unlike with F#. Maybe I should keep most metaprogramming with Nemerle after all. Less [keyboard] typing that way.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now