Thanks for your reviewing; I am absolutely pleased you found many things in Falcon "kudos"; for the rest, we'll do something before beta ;-).
Some note about Falcon:
Falcon is not meant to build BIG applications out of it. I.e. this is a clear statement in RUBY (a language capable to do small + large apps), and this is also somehow claimed but never quite attained by Python. The target of Falcon is to be fast enough to be a sensible choice over C for some duty, embeddable and powerfull to do small thing quite well. Also, yes, to be C++.
You know there's no problem in linking C in C++; the other way around is often more hacky, and that's was the reason of my choice. Also, I have proof of the fact that C++ compilers provide better optimizations for quite a lot of things. Finally... the api is more clear, and that's important to me.
A couple of precisations:
- About try/catch; actually, what you are going to catch is 99% an Error class or subclass item. The fact is that in 99% of the progrmas I noticed that selecting which kind of error have been raised is just a pain. So, if you really need that, you may easily use the switch statement over the error variable to detect it's error type. Remember that you don't have switch in python... so, having a pre-branch has more sense.
However, this is not a (completely) fixed decision. I may introduce a per-type or per-class catch filter later on, but the catch-all catch statement will stay. Also, the Falcon VM provides unstoppable exception, that may not be handled by scripts; they are not present in Python (i.e. you can block a syntax error if you use a catch-all statement), so a catch-all statement as LESS sense in python...
- Functions: static blocks are not just assignmens, but whole code slices done only once. Same for the class static statement: they are executed only when the first object of a class is created.
- Why starting with objects: we are programmers, and we know OOP, but I found in my teaching experience that newbies are better introduced to OOP if you first talk about objects, and then about classes. Also, I always felt the lack of singleton objects in every language I dealt; I used them in some contexts, and I felt quite comfortable with them.
- Attributes can be matched against expressions: they are NOT object or class specific. Once defined, you may assign an attribute to any object in your program. They are meant for EXTREMELY fast passage of data between embedding applications and internal scripts, (apps/scripts can read and set attributes without accessing the object structure and decoding the retreived item) but being a "trasversal" extra-oop thing, they may be useful also in a more general context. They are currently limited to 32, but before beta stage I will use 64bit integers; I am just considering if using them ALONE or continue to use also int32 if the number fits it.
- Stateful functions are an elegant way to implement stateful machines. This also allows to bind every function (or method) with a "state" value, that may be kept inside the function, instead of having to record and use the return value of it.
- Self and Sender objects are special registers of the VM, so they are not held in the stack, and do not weight in calls.
- The load statement is meant to provide a "logical" module loading capacity. The command line, that is, a minimal embedding application, will just load all that the script requires. More sophisticate embedders (i.e. your app), may filter out easily load requests and provide other things instead. Also, the embedder may provide its own function, objects and classes to the scripts, without having them to load any "application specific module". Falcon wants to be your application configuration language...
- In Falcon you can change the behavior of object and classes on the fly. I.e., instead of having a method to check if some condition exists and then act accordingly, you can just change the method depending on the condition.
Falcon is alpha. It may change a lot before beta, but I am currently quite satisfied with it now; I am just making module serialization more clever and much smarter object data access, but for the rest I am really happy with it. For the ppl that was lamenting lack of GUI, I will add an embedded AWT (abstract windowing toolking), something like the Java one but more focused on GTK concepts (that is, intelligent placement instead of fixed one, unless otherwise specified). So we'll have an AWT and many DRIVERS that will provide the AWT with real output.