Ogre Forums

Falcon Programming Language website : http://www.falconpl.org

I hear a lot on other related threads and forums that Falcon might be a very good alternative to Lua or Python (or Squirell, or ...) as an embedded scripting language. I'd like to hear more about people here that experiences using it, what went right, what went wrong, comparison to other alternatives etc.

In fact, I read a lot on the website and I'm considering it rather than Lua on my personnal game. As I'm not near the scripting system addition to the project, I can take time to think if something else would be more suited to my needs. But I don't have time trying to use it because a minimal test wouldn't reflect the real-world-with-a-team-on-a-big-game usage.

Now, here are some specific questions I'm asking myself about this language :
- lot of people says it's fast, but is it "thin", in memory at runtime I mean? (I think it would need some comparison to answer that...) Did you try it on NDS - does it fit in memory?
- it's easy to do context specific "language" based on Lua; Python, Ruby and Falcon may be more oriented to programmers than level designers for example (if they don't have a lot of programming notions). Are those kind of languages well received and used by non-real-programmer colleagues?

Real world experiences with this language really interest me...

I was actually planning on doing a big post on this, since just the other day I completed porting my 2d game engine from lua to falcon as a test.
Going from lua to falcon is very easy, although the docs on embedding are a bit lacking.

Here's some examples.

This is the lua code for shooting in my space invaders sample: Here's the same code in Falcon: They are identical apart from falcon not having the "then" keyword.
Of course that's only a tiny fraction of the language, using none of it's cool features. I just wanted to quickly port what I had.

But as you can see falcon script should be just as easy for non coders to use as lua, as long as you don't rely on freaky stuff.

For the c++ side, things are still pretty similar:
Here's one of my c++ function which I export to Lua: and here's the Falcon version: Both take a pointer to the language core (lua state, falcon vm). Both pass values by pushing them on a stack. Lua pushes return values on the stack too, whereas Falcon has an explicit return method to return a single value. Although if you return an array of values from falcon, it will automatically split them up if your falcon code tries to read multiple return values, so in both languages I can do something like this: It took a total of 2 days (not solid, I started late at night, went to bed, then finished it when I woke up) to learn falcon embedding and change my app so it can now run both lua and falcon at once. There's 43 exported functions, each one was hand written lua embedding and had to be edited for falcon (but most of that was just copy/paste). So changing between them was actually really easy.

For performance, I've found that Falcon is laggy in debug mode compared to lua, but that's odd because I use a release only build of falcon for both debug and release of my app, but a debug built of lua for debug builds of my app.
In release mode, I did some performance counter queries around the lua and falcon code, doing basically the same thing (nearly identical script code).
The performance counter results were around 800-1200 per update for Lua (that's moving multiple enemies, testing input, etc) and around 900-1300 for Falcon. Pretty close.
But as I said before, I'm not using Falcon's more advanced features (functional code, object oriented, etc).

I'm not sure about memory footprint yet

The only problems I've had so far are:
- global variables can be read but can't be modified inside of local code, unless you declare them inside the local code with the "global" keyword. Lua is the opposite, everything is global unless you put the "local" keyword in front.
- the garbage collection memory manager is a little confusing, especially since there's no docs on how to use it.
- a lot of the falcon wiki is links to unwritten pages.
- the forum is one user asking questions (and the author answering). There's only 40 or so registered members.
- falcon is unicode based, so getting strings in and out of it is a little trickier than lua's tostring and pushstring methods.

Falcon looks pretty nice, I should try it. Thanks for the pointer.

Have you tried Lisp with ECL? I did, I found it fun.

I'm not much of a Lisp fan. I tried it many years ago.


Some more cool Falcon stuff.
Make an array: If you don't like commas, syntactic sugar for an array is: If an array starts with a function, you can call the array as that function with the other array elements passed as arguments (an array starting with a function is called a Kappa and evaluating it is called K - Reduction): printl is like printf.

Make a dictionary (like a lua table or std map): Bless a dictionary (expose string keys as properties, like lua does automatically): Making things become a bit Lisp like: K-reduction and sigma evaluation of arrays Using lambda calculus to pass pieces of code around: This passes the code fragment x < y as an argument to the compare function.

Use a lambda to square all the numbers in an array (map applies it's first argument as a function to each element of the second argument): Making a class with members, constructor and a method:
This does a few fun things. First we make a class and instanciate 2 objects. The first is given the attribute enemy, the second is given friendly. Then we ask if the first object has the attribute (there's also the hasnt keyword). Next we iterate through every object containing the enemy attribute (an attribute can act as a set of all objects with that atribute) and print all their names.
The printing uses the string expansion operator @ which searches a string for a $ and evaluates the following word as a variable.
That's just a tiny selection, I haven't shown message passing, multiple inheritance, prototype objects, singletons, tabular programming, named parameters, meta programming, late bindings, coroutines, aliases, or the other fun stuff.

Really cool language!

And since it has a binding extension (albeit very young) which uses cpptoxml to automagically create binding code, we could probably hook up with the Python-Ogre guys. IIRC, they use cpptoxml too.

Hey, now that's a pretty cool language. For scripting languages, such things are fun!

Have you guys seen the 'io language'?

I hadn't checked the Falcon website lately, but I just saw today that Falcon 0.9 Albatros was released 2 weeks ago. YAY!
0.9 has speed improvements (especially with streams), a new multithreaded garbage collector, operator overloading (I've been hoping for that), a new fself keyword which points to the function you are inside of, added parametric evaluation, simpler lamba syntax, and other stuff.

Optimisation wasn't intended for 0.9 (speed improvements were side effects of other changes), but from 0.9 to 1.0 the focus will be optimisation and expanding the available modules. Possibly even JIT, but that's not definite.

Damn.

I'm already knee deep in Python integration.

Hello ppl,

I found you in some ego surfing I periodically perform to scan for Falcon adoption. I am Giancarlo Niccolai from the Falcon P.L. project.

First, let me thank you for the time you're investing exploring the topic.

Second, a couple of fast pointers that can be overlooked (our fault, we still need to write docs in that direction). Falcon embedding approach is intended to minimize the VM-to-app dead times. We have mainly two devices that perform that:

1) classes; In Falcon, the information about the object structure needs not to be stored in the object itself. You just need to wrap your data around a CoreObject and all the access information can be stored in the class data, having one place where the VM will look to resolve i.e. methods. Since 0.8.12 we have also automated reflection, that is, you can describe some automatic C to script conversions related to your structures. Since 0.9 you can bind your structures directly in a CoreObject class. Theoretically, you could simply use CoreObjects in your applications and hand them to the scripts when you need it (it's the Unreal engine approach, but made easier/faster). More on the reflection option matrix here.

2) Direct pointers. Falcon has native int64 values, which can be used to send robustly (i.e. 64-bit ready) opaque pointers through your scripts with no wrapping at all. Falcon functions are resolved at link time (no dictionary search is performed runtime on function calls), making operating on opaque pointers quite fast.

Other than that; Falcon is born for high performance integration in professional-grade multithreaded application (in the financial area). So, we serve the application the best we can: we have configurable callbacks from VM loop, sleep request control (we pass your app pause requests and you decide when to let the scripts proceed), several virtual functions in VM class that lets you expands many working mechanisms, standard stream overloading (you can write your application specific streams to pass data to scripts), module configurability (you can rip off easily functions you consider unneeded even from standard modules without having to recompile them), a "service" system (you can use many of the features our modules provide to scripts directly from C++ code without passing through the virtual machine), and many more ways to serve the host application.

We're in search of some open source project willing to adopt us as a scripting engine to build a public usage case, as I can't use the financial applications for which Falcon was born because they're are (highly) closed source and I am bound not to disclose their technology. So, if your project is interested, we may help you out with all our resources, and even use your experience to cooperate and improve Falcon specifically for you.

We're in contact with commercial game makers, as they found our engine to solve some problems that aren't addressed by LUA. A test with an open source gaming engine would be definitely an advantage for us, so we may invest some of our (scarse, atm) resources in making Falcon the best for you, and in integrating it.

TIA,
Giancarlo.


P.s. yes, the JIT is in our plans.

I'm really interested in Falcon but didn't have time to work with it yet. I'm working on an home-made game (not open-source, sorry!) so once I'm in the scripting system part of the project I'll try Falcon instead of Lua, maybe I'll be able to help this way.

We're in contact with commercial game makers, as they found our engine to solve some problems that aren't addressed by LUA.

May I ask witch ones exactly? We're using Lua on Nintendo DS games at work so it may be of interest for my coworkers too.

jonnymind wrote:Hello ppl,

I found you in some ego surfing I periodically perform to scan for Falcon adoption. I am Giancarlo Niccolai from the Falcon P.L. project.

Hi there

Maybey a first step is too finish the wiki topic Embedders Guide on your site? This will save you a lot of questions and more people who are not active on the forums will use Falcon.

Oh yes, that would be a very good thing! I lost a lot of time looking for documentation on embedding.

About the problems we addressed; I think I can excerpt some of the concerns in the mail of my counterpart:

Because we choose transparent binding, there are so many calls and accesses crosing language space and our overall system's performance slow down.

The problem with transparent binding in LUA is that it is necessary to map your structures to LUA types. This is unnecessary for Falcon bindings, as we separate access informations (the class) from the wrapping data (the object). More or less, you can inject your objects in the scripts without having to translate it into Falcon data back and forth each time. There's more: our structures allow to transparently work on your native structures from C++ and script at the same time (even from different threads) and see the changes reflected in the other side immediately. Of course, you may opt for opaque bindings (both in LUA and in Falcon), and then things get smoother in LUA, but the overall elegance of the result is way different. In example, consider that a script can effectively extend/inherit/override classes you create in C++ and that are reflected in the scripts. Doing this gets rapidly nasty with LUA.

Second, lua's key problem used for real-time application is incremental garbage collection performance.

In Falcon 0.8.x, our GC was quite similar to LUA's, but relatively less intrusive as it could run when the script was off. You may have chosen i.e. to disable GC and have it run at script termination, i.e. in a parallel idle thread. Also, scripts may gain GC control (if your app wants to allow them to do that), and so, use GC in optimal pattern/moments.

In Falcon 0.9, we have introduced a parallel cooperative generational GC. Without dropping raw GC performance, and without any impact on the run time, (like three state GC does), the scan moment is performed during VM explicit or implicit idle times (i.e. during sleep() or during waits for I/O calls), while collection is performed totally parallel. With proper finetuning, on a multicore machine Falcon scripts take virtually 0 application time in their GC scans; also on single core machiens, as we are able to exploit dead times, overall performance is smoother.

In both models, the application always gets a chance to be in complete control of what's happening in GC, if it doesn't want our standard system to be in control. Memory managers can be extended or replaced, or controlled by the application within the scripts by extending the VM, or simply asking for periodic callbacks to perform controls at spots.

Another aspect, less important to them because their scripting is all server-side, but maybe useful to you is the ability to provide different levels of service to differently privileged scripts. Other than extending our VM (it's a bit harder to replace LUA state calls; you have to rewrite parts of it), you can be in control of module requests to load/include other scripts, and filter out unneeded functions. I.e. if you want some scripts to just be able to manage bots, you may rip off the core module provided to them all the I/O functions. Several different VM subclasses, and several differently modified core modules/module loaders can be active in the same application at the same time (even in different parallel threads), so you're always in complete control of what a script can do and what it cannot. You may have admin server scripts able to mangle with the underlying OS, launch processes, read files and so on, while reducing client-side scripts to minimal logic-control abilities.

====

About the wiki guide: you're totally right. I stopped writing them because I was evolving the model, and they were outdated before being complete. The embedding model is now quite complete and stable (it's based on the binding matrix I linked above), so we're dividing our time equally among writing the updates for the user-level language guides, securing the official upcoming 0.9.2 release and writing the new embedding tests and guide. In short, we're on that.

Thanks again for your interest, and know we're at your disposal to help out.

Giancarlo.

Why would I choose Falcon over Squirrel for my next project?
Please, help me!

No, just kidding.
What I want to know is: Is Falcon used as an embedded scripting language in one or more professional projects? High performance, graphics/games projects?
I am eager to check Falcon out, but from looking at the site, it looks more like a business oriented scripting language?
While I like the feel of Falcon, I also like that fact that Squirrel grew out of experiences using Lua in game programming.
It sounds great that Falcon is performance oriented and built with multithreading in mind, but..

<edit>

jonnymind wrote:We're in contact with commercial game makers, as they found our engine to solve some problems that aren't addressed by LUA.

Oops - isn't it funny how your questions sometimes magically answers themselves just seconds after posting them?

jacmoe wrote: What I want to know is: Is Falcon used as an embedded scripting language in one or more professional projects? High performance, graphics/games projects?

I am sorry the one big professional project Falcon is currently employed (and I know of) cannot be disclosed for contractual reasons: it scripts the control system of a financial stream data network. I cannot say more, except for the fact that it manages the retail side of one of the most important financial institution in Europe. We're extending it to server logic control (i.e. real-time manipulation of streaming messages in financial markets). It's not a game, but our time constraint is around 3ms for the whole in-process-out time for messages, and our messages are taken from raw binary (at times even ASCII) formats, deconstructed, re-structured as maps of information-type=>information-content pairs and then serialized to be dispatched to thin clients. The control systems currently manage about 1500-2000 messages per second each (about 1-4kb per message), and the CPU consumption once enabled scripts isn't noticeable; that's why we're extending the scripting engine to the servers: we need to code some logic about the type-information elements and we don't want to hard-code it in the C++ engine of the servers.

Needless to say, all our servers and control systems are heavily multithreaded. This is why Falcon was born with the idea of being an easy embedding for multithreaded apps from the start.

And needless to say, all those constraints are way, way more demanding than even the wildest game around...

jacmoe wrote: I am eager to check Falcon out, but from looking at the site, it looks more like a business oriented scripting language?

Well, you can easily port any LUA script with simple refactoring, so if we're business oriented, LUA is too .

Anyhow, porting via refactoring is probably a bad idea: at 0.9.1, our main VM loop is about 30% slower than LUA, and we have no syntactic nor op-code optimizations. To have VM performances comparable to LUA you have to finetune scripts by hand (i.e. using ++a instead of a = a + 1, or use arrayFill() instead of loops to fill arrays). Up to date, we concentrated our efforts in providing a zero time in-out from the VM (thanks to the class-sharing system), and in 0.9, a zero-time cooperative GC and module caching. This makes integration in applications terribly fast (it's normal for us to measure callbacks in order of hundredth thousands per second; you can do something like that also with LUA, but forget about sharing objects with the scripts in that case).

We think we can reduce or nullify the gap in the VM main loop in 3-6 months or so (we have much debug/safety/old code in various parts, and many easy optimization just be fed in and tested out).

(Said this; some users reported Falcon being actually faster than LUA in some operations).

---

If you want to apprise some gaming ability, you may check out the latest SDL module.

Gian.

Oh, there is a thing I always forget to cite, but that's highly relevant.

While we're quite fast in "bindings", as we have classes that can reflect your application data without the need to recreate language-level properties each time you want to share an object, we also expose our libraries to the binding application. You can use our Falcon::String and Falcon::Stream classes in your application, and we have a relatively complete framework for multiplatform abstraction ready for your application to use. If your application is meant to be script-centric or script-driven, then you can easily use our facilities, which are ready to be integrated into foreign applications and extremely time-space efficient. This means that you can easily build applications where passing data to a script happens totally transparently. If you wish, you can even take advantage of Falcon GC and use it for your needs.

Also, many of our modules expose an interface class called "service". The service allows C++ applications to use the functionality exposed by the modules directly, without passing through a script. In short, the core functionality of modules are kept separate to be exposed to C++ code willing to use it. One user is the script back-end, and you can have your application use those too.

Hey jonnymind, is there a good place to read more about embedding Falcon in C++ application and exposing C++ parts of the application to Falcon? I did check out the wiki, but I was a bit... Lost.

Nice work on the language by the way, it seems really good.

nikki wrote:Hey jonnymind, is there a good place to read more about embedding Falcon in C++ application and exposing C++ parts of the application to Falcon? I did check out the wiki, but I was a bit... Lost.

I believe the documentation on the wiki is currently in the process of being rewritten. AFAIK the documentation is planned to be finished by the time 0.9.2 is out. I'm sure Giancarlocan elaborate further though.

Unfortunately I haven't had time to really play with Falcon beyond my initial porting effort (adding Falcon to my lua scripted 2d engine).
Apart from the lack of docs (for example having to read the VM source code to work out how the new operator overloading feature is used), I found it a fairly easy task. Both Lua and Falcon are extremely similar in the way they are used in an app (the code is different, but the concept is very similar).

Now that operator overloading is in (I like having vector math classes), there's no real problems with the language that I've encountered (does Falcon have Tail Recursion? It's the only thing I couldn't find, but it would be great for the functional side of Falcon).

For my own projects I'll probably be using Falcon as the main scripting language, although at work I still need to teach languages which are of immediate benefit to games coders (unlike certain other universities I could mention who's game programming teachers stick to their favourite academic languages like Scheme, Modula 2 and Smalltalk, instead of languages actually used in real games), so C++ and Lua will be the focus (I keep mentioning Falcon though, I'm trying to spread the word).

Tail recursion is part of the optimization techniques we want to introduce in 9.4 and 9.6 steps. Other are:
- Stack compression
- micro-allocation fine management
- link-time method resolution (via sparse matrix compression techniques)
- local symbol/expression caching.
- syntactic compile time optimizations (loop unrollings, loop flattenings, branch pruning, operator re-arrangements and so on).

As a design choice, we didn't introduce even a single optimization in up to 0.9. The idea was to start optimization since the code was stabilized, and that's happening with the first official version of 0.9 branch, the 0.9.2 release (scheduled for release in one or two weeks). In short, the tartget from now on is:
1) Optimize
2) introduce the 3 big topics left out from 0.8: logic programming, type contracts and arbitrary precision math
3) completing the existing paradigms (i.e. more fuzzy logic and game theory functions/operators for tabular programming).
4) minor usability issues as stabilization of the interactive mode and introduction of compile-time REGEX.

We plan to clear the field from the minor fuzz asap to concentrate on optimization on the last part of 0.9 development. Starting from 0.9.8 (due in about 6 months), we plan to perform every possible optimization still to be done, but we hope to get the most important ones by 0.9.6 (due in about 4 months).

Many things depend on the amount of support we can have from developers in the community, but I can already count on several motivated and active members, and we're hopefully getting more soon, so plans should go smooth.

Lately, we gained also people helping out with docs, so we think we can provide a more complete and organinc guide for embedding and module writing soon.

Btw, we just completed the new survival guide: http://www.falconpl.org/index.ftd?page_ ... ival+Guide (as I write, the last new thigns are being proofread); the survival guide is not a good "introductory guide", but it is a necessary working-paper document where everything about the language is written in a reference-like fashon. There's also a paragraph on operator overloading in the "object & classes" chapter

Giancarlo.

P.s. thanks for spreading the news, we need it badly!

Considering how well it already runs, I can't wait to see what the optimised versions will be like.

jonnymind,

Your very detailed explanation caught my interest as well. Thanks for your effort!
I look forward to take a closer look at falcon in the next month for our application.

xad

For those who don't know it yet and are interested in the news, Falcon 0.9.2 is out !
More infos : http://www.falconpl.org/

We've never used script languages really before, but nows the time. We're looking to try Falcon amongst others, most likely Angelscript since it's syntax is c++.
The only embedding stuff I found was the examples code, which look fine, but they're for version 8 and you mentioned some major 9 changes. Is there any 9 embedding docs/code?
One thing with angelscript is it looks really easy to bind functions (btw Raknet RPC3 binding is super easy and transparent, why can't script embedding be like this?).
Falcon looks considerably more involved. I'm not sure why and I'm sure there's a good reason, but any 9 docs would help

A nice easy tutorial like this would help scripting newbies to adopt this http://www.gameengineer.net/tutorials-angelscript.html#