The Trinity Project

There are far too many different programming languages for far too many different purposes. The obvious solution is to create yet a new one. Trinity is conceived as a single language that can be used in many places, and for many different purposes.

Trinity is so named because it is actually three different languages. A scripting language, an application language, and a system language. The three languages are very similar, and can very easily interact.

Trinity Script: This is a simple language intended for system scripting, embedded uses, and special purpose environments such as scripts embedded in web pages (ala PHP, or JSP). All variables are typless. The details of class definition and class typing will require very careful consideration.
Trinity Application: This language is similar in nature to Java (as a language). It strong typing and strictly controls random memory access (unlike C++). This language is intended for standard application development.
Trinity System: This language is similar to C++. It includes the language elements of Trinity application, but also includes mechanisms to bypass typing, and perform low level memory access. This is intended for system programming, system libraries, and situations where low level performance is critical. Integration with assembly code is simple. It is possible to write code in this language that requires no outside libraries, and integration with runtime services (such as garbage collection) can be explicitly control or manipulated.

Trinity is a fully object oriented set of languages. All types are defined as objects, including standard types such as Strings, Integers, or Floats. Exceptions, assertions, garbage collection, run time typing, and reflection are all part of the language(s).

Inheritance of interfaces, and implementation are both supported seperatly. Multiple inheritance of interfaces is allowed, but multiple inheritance of implementation is not.

All operators are defined as syntactic sugar for calls to methods on the objects in question. Constant expressions are defined as syntactic sugar for calls to the constructors of the appropriate type. An appropriate mechanism for jump starting this process must be possible at the system level.

The runtime environment should allow different sections of a program to be "linked" together seemlessly, even if different portions of the program are written in different parts of the language. This means that a call to a method written in the script language should be syntactically identical to a call to a method written in the system language when called from the system language (and all the versions of vice versa). This does NOT mean that the compiler is unaware and cannot optimize, only that the syntax is identical. This should be the normal way of providing system libraries which can potentially be written in any of the languages.

The Script and Application languages should be platform independant, though platform specific libraries may be avilable, and would make the application produced plateform specific, if used.

When programs are developed, support for a new running environment (command line, versus GUI, versus system service, etc) should be a matter of subclassing a framework class appropriate to the environment. The command line class gives access to stdin, stdout, stderr, while a GUI framework doesn't. These classes are not magic, and it is conceivable that a command line program could create and invoke the GUI framework, etc.

The selection as to which framework is used is either made at compile time, or at run time. There is NO difference in the code base. There may even be multiple versions of the same environment in the same code base. For example, a user command line version, and a command line version intended for use inside a testing harness.

The scripting language uses typeless variables. This 'varient' type is a first order type in the application language. Assignments from this type to other types are allowed, but checked for correctness.

It is intended that optimizing compilers work at a high level, and that the language is designed to facilitate this, but that optimization features of the compiler will not depend on explicit programmers. This means that while the compiler may chose to inline a method, there is no 'inline' keyword.

Home | About Me | Originals | Programming Docs

garrett@bgb.cc