LiveCodeish

Livecode Builder extensions will be based upon a "new dialect" of LiveCode (let's call it LiveCodeish.

Essentially the dialect will be a distilled form of the current LiveCode core syntax and semantics - this syntax will be cleaned up and its functionality will be much better defined (for example, getting rid of auto-conversion of arrays to empty strings and "fixing" the non-standard "for x to y" loop we have).

The first is that this new dialect will provide the ability to directly hook into native code through binding to functions in native code (whether that be Java, Objective-C or C/C++) thus, hopefully, eliminating the need to write "glue-code" externals and, again, making extending LiveCode much more accessible to anyone that can code in LiveCode rather than those few who can, or have the time to delve into these lower-level environments.

The next is that it will (eventually) be typed in a very natural way. You will be able to declare variables and handler parameters as having a given type (by default their type will be any).

Whenever you try to assign a value to the variable the engine will attempt to convert it to the appropriate type and only throw an error if this is not possible.

For example a variable with an integer type can have an integer put into it directly, a real number can be put into it after its been automatically rounded, and even a string can - as long as the string can be converted to an integer.

This simple ability will mean that it will be easier to write "correct" code - you'll be able to much more easily debug things where it could be type-mismatches that are causing errors.

It also means that (in the future) suitably typed code will run more efficiently - for example if you have an integer variable then that can be much more efficiently represented internally than a variable which can hold any type.

The third thing about LiveCodeish which is quite different from normal LiveCode scripts is that there is no message path - well, the message path is there, it's just that command and functions in extensions do not sit in it.

This is exactly the same situation as current engine commands and functions - they are bound at compile time. This not sitting in the message path does not mean that extensions have no access to it, quite the reverse as they will have access in the same way as engine syntax does - you will be able to send messages to objects through the message path just as the engine can.

This slight change in perspective brings LiveCodeish much closer to more "traditional" languages - and means that over time a much larger range of optimization potential becomes available (as things are more static in this world - dynamicity is great, except when you want to optimize at compile time!).

Indeed, I can see no reason that LiveCodeish should not be eventually compilable to native code with performance at a level where the decision to code something in C or LiveCodeish due to that metric is a non-issue - LiveCodeish will be amply able.