Skip to main content.

Archives

This is the archive for 16 May 2008

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.