Beyond the door... there's peace I'm sure.
And I know there'll be no more... tears in heaven.
- Eric Clapton and Will Jennings
Introduction
There is no single definition of a scripting language, and it means different things to different people. Those traditionally referred to as scripting languages can vary widely in terms of syntax, capabilities and size of run-time environment. Some of the things oftentimes associated with a scripting language or scripts themselves include:
♦ Scripts tend to be small to medium sized programs, oftentimes to automate tasks within a specific environment.
♦ A Scripting Language is typically interpreted, and is oftentimes not strongly typed.
Many scripting languages tend to have "more radical" syntax than traditional programming languages, oftentimes to get multiple things done in a single, yet complex statement. As mentioned above, scripting languages are typically not strongly typed, and do not require data items to be explicitely defined.
The author loosely considers Aztec a "high-end" Scripting Language, and the umbrella class in the Aztec framework is even named 'Script'. By design, Aztec is somewhat of a hybrid, based on the scripting attributes mentioned above. It is a fully featured, strongly typed object oriented programming language, yet it also allows global methods and data, more in line with traditional command driven scripting. It is a strongly typed language, yet it supports the implicit creation of local variables within the context of a method. The Aztec Engine can be run in an "interpretive" mode, but also supports a separate compile mode to create a binary executable file, which can be executed at a later time.
One of the primary design goals of the Aztec Programming Language was to provide a full featured object oriented language with consistent and clean syntax, multiple inheritance capability, a powerful class framework, but with a "scripting language" feel. The Ultimate Scripting Language.
♦ An Aztec source file can be executed immediately or it can be compiled into a binary executable file and executed later.
♦ Aztec Engine also provides the Interpret UI which allows the user to dynamically execute Aztec source code statements in the context of a running Script.
♦ Aztec is a strongly typed language that provides mechanisms to convert references based on the actual type of an object.
♦ Using the '-implicit' flag, a data item can be created and used without explicitly defining the item, based on the context in which it is used.
♦ Complete OO language, but also supports global methods and data, with very flexible visiblity control.
♦ Very strong Event driven services are provided, but an Aztec Script can also be run using a traditional "procedural" programming model.
The Aztec Programming Language and the features in the Aztec Engine software provide the developer with a unique combination of power and flexibility in a compact solution that is unique in the industry.
Language and Virtual Machine
The "Aztec Summary" page contains a high level summary of the Aztec programmming language and class framework. This section is sort of a summary of that summary, with an emphasis on some of the more interesting aspects of the language and framework.
Aztec is a fully featured OO language with friendly syntax, minimal complexity and thoughtful use of keywords.
♦ True multiple inheritance (instance data in multiple base classes) and polymorphism are supported.
All primitive data types are real Aztec objects.
♦ Simple set of only four primitive classes.
♦ Primitive objects can be used as values (in mathematical expressions) and references (method args, primitive reference variables, etc.).
♦ Each primitive class provides three comprehensive sets of methods - compiler, global and instance.
♦ Compiler methods are executed at compile-time while global and instance methods are executed at run-time.
♦ Each global and instance method is implemented internally as a VM instruction, maximizing run-time performance for the entire library of primitive run-time methods.
Method can be defined within a class or at the global/module level, and they can also be executed during the compile phase.
♦ Method arguments can be "pass by value" or "pass by reference", and methods support default arguments.
♦ Arrays references and method references can also be passed as method arguments.
♦ Method names can be overloaded as long as each implementation has a unique argument list.
♦ Methods can be defined as 'sync' so Virtual Machine automatically synchronizes access across multiple threads.
Visibility options are very flexible, and satellite classes add to the flexibility, so a class can be defined in more than one location.
♦ Satellite classes are also used during dynamic code generation to add data and methods to a class at run-time.
Aztec provides support for method references with a completely type-safe implementation (validates argument/return types).
♦ Entire method signature is part of the method reference definition (argument types and method return type).
♦ Compiler and VM maintain complete control over the method reference. They never let a method reference variable be assigned a method reference that doesn't match the return type and the arg types.
♦ A method reference can be taken for a global/shared method or an instance method.
♦ A method reference can be passed an argument to a method and can be returned from a method.
♦ Very useful for event handlling.
♦ Method references support a special "base method reference" data type and can compare and convert from base to specific method reference - using 'is' and 'as' - consistent with 'Base' for Objects.
Multi-dimensional, dynamic arrays are supported with methods for sorting, resizing and other array manipulation.
♦ An array reference contains the data type contained in the array, as well as the number of dimensions defined for the array.
♦ VM maintains complete control over the array reference. It never lets an array reference be assigned an array that doesn't match the type and number of dimensions.
♦ An array reference can be passed as a method argument and can be returned from a method.
♦ Arrays also support a special "base array" type which works in the same way as the "base method reference" works ('is', 'as', etc).
The Aztec Build system performs multiple compiler steps to allow identifiers to be seen across modules, and it also provides the programmer with a powerful and easy-to-use model for performing logic at compile-time.
♦ Compile-time logic is consistent with standard Aztec syntax - there is no separate preprocessing language.
♦ Includes conditional execution, full expression evaluation, all flow control statements, and a powerful library of system methods such as File I/O, dialogs and system utilities.
♦ Help files and static data files can be processed at compile-time and become part of the Aztec bytecode, so they are not needed at run-time.
Aztec provides parameterized template classes, allowing one or more classes to be "passed in" to the class that is being created. This feature allows a class to be created that operates with one or more generic classes, and when an instance of the class is created, the actual class(es) are used. This results in a version of the class that works specifically with the type of class that the programmer needs. Code can be written once, and then it gets re-used automatically for every instance of the template class that gets created.
The Aztec Virtual Machine manages all stack and dynamic memory, and the user does not need to worry about it. But Aztec does provide the programmer with control over how an object is cleaned up as it goes out of scope. An object can be destroyed in the foreground or the background, and this setting can be applied at the the script level, class level and object level. Foreground object cleanup leads to the concept of deterministic destructors, so the script can reliably, predictably clean up an object, and possibly release an important resource, prior to some other task or thread needing that resource.
The Virtual Machine provides a completely safe execution environment.
♦ All critical services are monitored and exceptions are fired when necessary. Math operations, file I/O, socket I/O memory and window I/O are handled automatically.
♦ Object memory cleanup is handled automatically by the Virtual Machine, and the system ensures that object references are valid at all times.
Class Framework
Events are an integral part of the Aztec Engine system, and it provides a flexible and easy-to-use event handling model that is consistent across the class framework.
♦ Three separate options for handling events, including method references and virtual interface classes.
♦ An Exception is an Aztec Event, and standard exception handling in the offending thread can occur simultaneously with event handling across multiple threads based on the same exception event.
Aztec provides a variety of useful utility and I/O classes, including the following.
♦ Utility classes for date/time manipulation, timer alarms and template based collections
♦ Flexible and consistent family of stream I/O classes including file I/O, memory I/O, socket I/O and stream filters
♦ Family of system Metadata objects with real-time information about the running Script. Classes include Metadata, Unit, Module, Class and Method.
The system offers intuitive multiple thread support, with each instance of the Aztec Thread class tied to is own, independent operating system thread.
♦ Flexible synchronization and thread communication features are provided.
♦ Thread to thread and thread to Script messaging features including text, binary and object messages.
♦ Messages can also be sent to remote Aztec Scripts across a network or the internet.
The Script class provides mechanisms to dynamically generate and compile Aztec source code on the fly and immediately make it available to the running program for execution.
♦ Dynamically updates class and virtual method hierarchies for the running program, which can also change the behavior of already existing code.
The user interface framework is easy to use, thread safe and it provides consistent event handling across the UI framework as well as the entire Aztec class framework.
♦ Supports the capability to display the UI on one or more remote machines and process all UI events locally.
♦ The Aztec Engine runs in special "UI Display" mode on the remote computer and performs all UI services, sending events back to the client Aztec script for processing.
Why Aztec - A Better Scripting Language
