Skip to main content.


This is the archive for May 2008

Sunday, May 25, 2008

Version 0.8.10 has been officially "complete" for about a couple of weeks now; however, before releasing, I wanted to stuff in three last features.

This is because after the release I want to keep the core system stable for a while, and concentrate on the module development and on the site management. We need libraries, we need a more falconized site and we need more people joining. So, the activity in the next months will be that of adding libraries and advertising Falcon around.

This Piuma version addresses a series of issues both in the language and in the engine, and adds some very important feature which complete the support for the programming paradigms we support. I am quite happy with it, and I think it can be a good base to develop modules. Just, before going on with the rest, I wanted to prepare the core and the VM systems for the tasks needed between release of 0.8.10 and the starting of 0.8.12.

Version 0.8.12 shall be the last of the 0.8 series, and will complete the engine, the internal API and the API of core and RTL. It's tentative name is now "Condor", as the intention is that to take a look from afar, fly high and placidly to view the ground from high above. A complete and final review of the code before starting series 0.9, that is final optimization steps before 1.0.

So, in the time between the Piuma release and the starting of works on the Condor engine, I wanted to have this three features ready:
- Multithreading pluggable support.
- Internationalization support with i"" strings
- Hooking for Virtual File System providers.

We have achieved the first two items; now, the engine has a slot for atomic reference counting and global locking (the latter currently unused) that can be hot-swapped by loaded-in modules. Multithreading module sets in its own "lock providers" so that atomic reference counting and proper locking are available when MT is used, and are linked with MT libraries only through the plug-in module. The way the mechanism is done is currently not very elegant, but it works (well) and it can stand till we review all the code on the Condor release.

About the last point, Falcon will have Virtual File System support plugged in the engine. In the beginning, I thought to provide a map of VSF providers, generating Streams based on the URI they received, directly on the VM, as the service system. But working at the MT pluggable support, I realized that the best way to do that is to review the whole pluggable system and give the ownership and control of all the pluggable support to the ENGINE (that is, the main Falcon DLL loaded by the embedding program). As such, the review of this and other aspects (as the Engine data, the Service system and the new MT support), is delayed as the very first activity of the Condor release.

So, the release is complete as it is now. The only "code" missing is a small installer utility that I wanted to be ready by the time of release, but being a separate project and being dedicated to modules, we can work at that right after the release.

Friday, May 16, 2008

I was reviewing a bit of common LISP documentation in search for possible design flaws of our functional programming support. I realized that we have actually something a bit more powerful than the original LISP, as we have the ability to inspect and change the processing lists after they are created and even while they are being processed, and we hold an overall control of their processing sequence, which can be managed by both the scripts and the embedding applications.

However, we miss a relevant feature: automatic binding of symbols in lists. We have substituted that with pass-by-reference semantics, as in the following example:

val = nil
eval( .[times $val .[.[printl $val]]] )

This works, but all the symbols needed in the list evaluation must be declared in advance, and they cannot be "closed" (as in functional closure). This limit the potential of our model.

I have found a way to provide arrays with symbol tables, as if they were functions or objects; also, it theoretically possible to access an array by object accessor like this:

sequence = .[printl &text]
sequence.text = "Hello world"
eval( sequence )

This would be quite a leap forward in our model, as we could externally bind anything with a variable in a functional construct, including other functional sequences. Also, this would allow inspecting functional sequences after their evaluation, exploiting at the fullest the "impure" functional model we picked.

The problem was... how to declare a symbol so that it stays local to the array sequence? (There are other smaller problems as well, as deciding the scoping of the declared variables, but one problem at a time).

The character "&" came immediately to my mind, but it was busy for the bitwise "and" operator. After a fast check, I realized that I have used up all the available one-character operator-like symbols commonly available on computer keyboards.

So, I realized that occupying three important "symbols" as "&", "cap" and "|" for operations that are rarely used was far from wise. We won't probably be able to stack this latest evaluable lists symbol table idea in this version we're releasing, but as I want the language and the engine to be somewhat stable for a long period before starting the work on 0.8.12 (and then 0.9), I decided to change the binary bitwise operators into "&&", "||" and "cap cap"; also the unary "not" bitwise operator is changed to the tilde symbol "~".

I know this may create a bit of confusion in C programmers coming to Falcon, but bitwise operators are a very rare feature in scripting languages anyhow, so rare that they may probably be declared through pseudofunctions, as bAnd( a, b), and few would complain (if someone at all). This frees up "&" for our needs, and also frees up "cap" and "|" which can be used for a whole lot of interesting features. Operator combinations as our dot-bracket ".[" are a good way to increase the number of available symbols, so "cap" may be used to modify the meaning of a following operator, making room for more things.

In this way, we'll be able to add the "&var" support as a drop-in somewhere after the release, without having to make incompatible the previous scripts.