Philosophy

Embeddable languages must work in a variety environments and must be flexible enough to adapt to different requirements. As a result, the primary philosophy behind EXPL is making the language more independent of the programming environment. This is accomplished in several different ways:

1. Modularity. One of the most important design goals was modularity. The compiler, loader and interpreter needed to be contained in separate, independent modules that had no device dependencies. This enabled the same code to be used in any application without any need to rewrite or customize the core modules of the language. The device dependent parts of the code could then be added in the form of intrinsics and other supporting code.

2. Pluggable. In order to allow the compiler, loader and interpreter to be used in any environment, these modules must have very flexible interfaces that can adapt to any application. This is accomplished by providing multiple entry points to the compiler, loader and interpreter.

As an example, the compiler can take strings, streams or files as its input or output. This means the compiler can be used in the traditional manner, reading XPL files from disk and writing back I2L files. In addition, the same compiler can also read XPL sources from strings and output I2L codes to strings. This allows the compiler to be packaged with other tools to form a stand-alone programming environment.

Code Declarations. The flexible interface model solves another problem with XPL0. Standard XPL0 requires that the user have a code declaration file installed somewhere on the hard drive. In addition, the user must remember to add an "include" declaration in the code. These are unacceptable for an embedded application where the goal is to give the user a simple, easy-to-use programming environment.

The solution is to have the programming environment inject the intrinsic declarations at the beginning of the XPL source code just before the compile operation. To the user, the intrinsics simply appear to be part of the language, just like other basic commands. The operation can be done with library subroutines.

3. Device Independence. The standard intrinsics in the original version of XPL0 are highly device-dependent. Many functions are tied to MS-DOS and its idiosyncrasies. In addition, many XPL programs directly access hardware ports, registers and memory locations. This makes XPL programs very non-portable, and moving a program to a different environment requires lots of code rewriting or even a complete redesign of the program.

In contrast, newer languages often come with libraries and frameworks that make porting programs from one environment to another relatively simple. For example, Delphi uses something called the "Visual Component Library" (VCL). The VCL provides an interface to the operating system and other computer resources that is logical and well organized. Since the VCL changes from operating system to operating system, your programs automatically run under Windows, Linux or the Mac OS.

As a result, one of the goals of this version was to experiment with creating an intrinsic set that could give XPL0 similar portability. This resulted in an Extended Intrinsic set that handles all common tasks, including advanced graphics operations. The intrinsics were designed with the following goals in mind:

1. Common Units. Many standard XPL0 intrinsics take unusual units for inputs. For example, the Sound intrinsic takes a time argument in units of 54 milliseconds. Likewise, the original Line intrinsic expects color data in the idiosyncratic format of each of the particular VGA modes you are using. To solve this problem, the extended intrinsics have a new LineTo intrinsic that works in every possible video mode by using a red-green-blue color argument. This puts the responsibility for handling device dependencies in the hands of the intrinsic, which is responsible for converting RGB color to the nearest available color value.

2. Universality. Rather than having lots of intrinsics for many different situations, the individual Intrinsics should work in as many situations as possible. For example, all graphic operations in the extended intrinsics are carried on "handles." Handles can represent the video screen or a bitmap. That means, for example, that the LineTo intrinsic works for both the video screen and bitmaps, so all the programmer needs to do is change the handle to redirect lines to a different output.

3. Speed/Power. The typical reason for creating non-device independent XPL code is the speed advantage of directly manipulating the hardware. Properly written, device-independent intrinsics can be as fast or faster than non-device-dependent code.