Although an interpreted language does sacrifice performance for programmer productivity, the rationale is that most Windows applications (other than the relatively few that are commercial, shrink-wrapped products) are not very performance sensitive. They spend much of their time waiting for the user, calling Windows, or calling dynamic link libraries for database access and other performance-intensive operations. The advantages for Liana being an interpreter are comprehensive runtime checking and protection; friendlier run-time error messages; fully-virtual, Smalltalk-like member-function dispatching, based on object value rather than compile-time declaration; and more flexible treatment of function arguments and variables to reduce the amount of code and make it less cryptic and easier to modify and extend.

main
{
   (w = new window("Hello World")).show;
}

window w;

void main (void)
{
   w = new window ("Hello World");
   w.show ();
}

The Liana library contains a default main function that creates a window and makes it visible, using the value of the global variable apname as its title. So we get the same results with:

apname = "Hello World";

Liana will set the initial value of apname to the executable file name if the application has not initialized it to a non-null value. This causes an empty Liana program to display a window titled with the program name. Although the program name is not often an appropriate window title, this example does illustrate how well the default behavior of Liana works.

The following program will draw a small circle in the center of a window, regardless of how the window is resized by the user:

paint {w.center; w.circle (10);}

Note that Liana's version of hello.world omits the #include statements. Liana does not need and does not directly support #include files. Unlike most compilers, Liana shifts name resolution to the linker. For example, the compiler does not care how you define the window class, even if you derive a new class with member functions that reference members of the window class. This results in a radical reduction of the amount of work that the programmer must perform to keep the compiler happy.

The design philosophy of the Liana class library eliminates most of the need for #define. For example, many of the bits and fields of the Windows API are controlled by simple, high level member functions such as:

w.background = "r"; // Red background
w.caption = true; // Enable title bar

A major departure from C is that variables are merely containers which are capable of containing any type of value. In fact, the type of value in a given variable may vary during the execution of the program. You may omit the type when declaring a variable, or you may specify C-like types such as int, short, long, unsigned, double, char *, or the name of a class. The any type is provided for cases where the type may vary.

String, boolean, and null types are predefined in Liana to simplify setting up an application. There is no need for header files that define TRUE, FALSE, NULL, or conventions for strings. The null value has its own type which differentiates it from zero, although its value is zero in numeric expressions. The boolean values true and false are different from 0 and 1, but equivalent in numeric expressions.

Variables do not need to be declared. Undeclared variables have global scope. Although this can allow bugs to slip through, it simplifies prototyping, keeps the source code simple, and eliminates another need for header files. Programmers may still provide declarations for global variables for documentation purposes.

Local variables may be declared anywhere in a function, including expressions, by merely specifying a type before the variable name. For example:

a = b * (int x = y - z);

All variables are initialized by default to the null value. This guarantees consistency and eliminates superfluous code to initialize local variables.

The syntax of functions is very similar to C. The major difference is that the types of the return value and parameters need not be declared. But the programmer may certainly specify types, primarily for their documentation value. Every function has a return value, with null being the default return value. It is possible for a function to return values of different types on different calls.

Class definitions are similar to C++, but they support only single inheritance and all member functions are virtual and are defined within the class definition. You don't need both a declaration (in a header file) and a definition since class and member references are not resolved until link-time or even runtime.

One interesting extension is that public member variables can be implemented either by using the public keyword for direct access or by supplying a pair of access functions for controlled access. The application references the member variable the same in either case, using structure member access notation. For example, to access the menu of a window the programmer codes

w.menu = new menu;
m = w.menu;

w.menu_set (new menu);
m = w.menu ();

Liana automates memory management using a reference counting scheme. This means that objects and strings allocated within functions will automatically be freed when the function returns unless the values are stored in other than local variables. The free function can be used to break cyclic data structures.

A Liana application requires a runtime DLL which consumes about 180KB. The .EXE file for a typical application will consume under 200KB. This is very modest considering that Windows machines are typically equipped with several megabytes of RAM.

Liana eliminates much of the need for make files by eliminating the #include dependencies and automatically comparing dates of source files and their intermediate files.

The Liana programmer declares a DLL entry point using the usual function syntax, but with an entry-point specification string rather than a function body. For example, the GetTickCount function of Windows which is defined in the USER DLL is declared as:

unsigned long GetTickCount ()
 "user: GetTickCount"

Another method of accessing C code is to use Dynamic Data Exchange (DDE) to communicate with other applications. DDE is a protocol for passing data between applications. Besides peek, poke, and remote command execution, applications can request notification of changes to named data items.

Although equipped with a very simple compile/link process, a Windows-hosted integrated development environment (IDE) would make Liana more useable. Liana does not currently have a debugger, primarily because it is such a high-level language that bugs are much easier to track down. The addition of a debugger would make Liana more attractive to a wider audience of C programmers. The IDE and debugger will be written in Liana, allowing C programmers to easily customize and extend them. A current prototype of the IDE is only 150 lines of code! The debugger will run as a separate Windows task and communicate with a stub in the application using DDE.

Market pressure may force Liana to be outfitted with an interface to a browser and visual layout tools. But they won't provide as much benefit as they do with other languages and libraries.

Liana was designed to be portable and will probably be ported to one or more of the other popular GUI environments. Existing Liana applications will then be portable to those environments with very few, if any changes.

Objections to the interpreted nature of Liana would be somewhat resolved by a translator which generates raw C or C++ source code. Unfortunately, features such as the Smalltalk-like pure virtual member-function dispatch would require additional runtime tables and interpretation, so the performance gain would be less than expected. Liana classes would not be totally compatible with C+ + classes.

The compiler might be extended to support a compatibility option that would selectively enforce a subset of Liana which is 100% compatible with C and C+ +. Changes and additions would increase the compatibility between Liana and C, but not force the programmer to give up the advantages of Liana where they are really needed. This has a lot of appeal and would improve performance.

The original prototype of Liana included a tightly integrated object-oriented database management system (OODBMS) which allowed the application to create objects in the database and then access them as if they were in RAM. This feature was shelved due to the pressures of getting Liana to market, the need for additional transaction and concurrency control features, and concern that the market was not yet ready for an OODBMS. Such a feature will probably be in great demand within a few years and will then be a very natural extension to Liana.

Liana also shows the versatility of the C language syntax. There is still enough mileage left in general-purpose programming languages such as Liana to give them an advantage over specialized user interface languages. Programmers do not need to switch to complex visual environments or languages like Smalltalk or BASIC to reap the benefits of OOP and simplified GUI development.