The Falcon Programming Language in a Nutshell

Because attributes are a very flexible means of declaring dynamic Boolean properties and a set of “similar” objects, we have used them as the main driver for message-oriented programming.

Basically, objects and instances with a certain attribute can receive messages built for that attribute's holders. The target objects will receive messages through a method named after the attribute.

The rest of the message-oriented programming support is built on this basic mechanism—message priority queues, automatic event dispatching, inter-agent messaging services and so on.

As a minimally meaningful sample would require 50–100 lines (messages are among many agents), we'll skip it here, and try to explain what's nice about message-oriented programming.

The main point is that you can summon remote execution in unknown objects willing to participate in the message without direct knowledge of them. Messages can carry anything, including methods or whole Sigma sequences for remote execution in foreign objects.

Messages don't even need to be point to point. The message receivers cooperatively can form a reply by adding something to the forming return value. For example, a central arbiter can send a “register” message, and every object willing to register can add itself to a queue of items willing to register in a queue traveling with the message. The queue even can contain target register procedures to be invoked by the arbiter once the register message processing is complete.

An example that easily displays the power of this paradigm is the implementation of an assert/retract/query mechanism.

A central object registering assertion listens for messages of these three types. Any part of the program then can send an assertion, a name bound with executable code, which can be anything, including code generated dynamically or loaded from plugins. Items in need of some algorithm can then query the system (sending a query message) asking for it to be provided.

If available, the code is returned, and it can be invoked by the agents in need of it.

You also can do this through a global dictionary, where code is associated with algorithm names, but that approach requires all users of the code to know the central dictionary and to interact with it. Asking a smoke cloud to take care of arbitrating the code repository is easier, simpler, more modular, more flexible and allows for central checking and managing. When that comes at no additional performance cost because of the language integration, it's an obvious advantage.

Stuffing all the things that Falcon can do for you into a short article is not easy, mainly because the things some will find useful may be useless for others. We didn't discuss co-routines, the indirect operator, the upcoming tabular programming, the reflexive compiler, the Falcon Template Document system (our active server pages), the multithreading module or many other things we've done and are doing to make Falcon the best language we can.

A DBI module already is available for interacting directly with MySQL, Postgre and SQLite3, and ODBC and Firebird will be ready soon too. A module for SDL is standing, and we're starting to work on a generic binding system to provide full support for Qt, GTK, GD2 and many other libraries.

We are still a small group, and the language specifications are still open. So, if this project interests you, and you want to add some binding or test some paradigm/language idea, we welcome you.