 |
Transframe: A White Paper |
|
|
Transframe: A White Paper |
"Language is the dress of thought," a very expensive dress that we cannot afford a change. Unfortunately, our thought often outgrows our language so fast that we always need a new language, which might cost us a life-time learning. If we ever need a new language, we should pick up the one that can spread as our thought grows, and can transform as our thought changes.
Transframe is such a language.
The design philosophy of Transframe is to provide a diversity in terms of a simple, transformable framework that can be adapted to various specific problem domains.
Transframe provides a framework that can be adapted to achieve the power of dynamic typing for rapid development, but can also be transformed into static model to preserve the efficiency and quality of the current static typed languages. The gap between dynamic programming and static programming vanishes. Transframe enables a software development environment that provide run-time class/function creation and modification and the power of polymorphism provided by a dynamic language. Meanwhile, Transframe enables a software product that has the equal size and speed to the equivalent product developed by traditional static languages. The framework produces models (classes) that can be frozen and melt freely between dynamic/static environment. The penalty is scalable depending on the required degree of dynamicity or polymorphism for a final product.
Existing programming languages usually provide a built-in model for a very limited program domain. For instance, to enable concurrent programming, Ada provides task, Actor has active object, SmallTalk uses process, and Java has thread and synchronized method. Unfortunately, application requirements may vary greatly. For example, different distributed systems may require different architectures such as client-server, peer-to-peer, and master-slave. A single built-in model is a rigid dress that can never fit well to each requirement in our thought. The framework provided by Transframe that can be transformed into high-level models for different requirements in various domains such as concurrent programming, distributed programming, parallel programming, database applications.
The diversity of Transframe does not make the language a heavy dress. The framework is designed in a simple class concept which is generalized to cover a wider domain. The language clarifies and unifies many concepts which are obscure or ad hoc in other programming languages. Examples are nested classes, object references, array types, and type dependency.
The flexibility of Transframe does not make the language a loose dress. While the framework itself is flexible, the model created by the framework is well defined. The specification of interfaces or contracts in using these models are more precise than conventional the ones; so that they produce fewer run-time or link-time errors than that was developed by traditional static languages such as C++ and Eiffel.
The power of Transframe does not make the language a knotty dress. The syntax of Transframe follows conventional language design. Instead bringing about brand new concepts, Transframe provides a natural extension to the ordinary concepts that have been commonly used by other popular object-oriented programming languages. The syntax of Transframe is very similar to C++.
People have gained an appreciation for the necessity of a dynamic programming environment for rapid application development. This environment helps us create applications such as user interfaces, animation systems, and simulation tools quickly without extensive traditional coding due to the following:
- direct product deployment from rapid prototyping, and
- domain-specific language and visual development interface
However, most of our software engineers are still developing their applications using traditional static coding. Today's technology is changing so fast that they are almost certain to find that this traditional method hinders them from keeping with the change. Our current baseline position contains two significant obstacles:
- lack of suitable rapid development technology that supports space and speed efficient product deployment, and
- lack of domain-specific language and visual programming methods for diverse computation models.
Due to the lack of suitable rapid development technology, current programming languages and software development environments force developers to choose between a dynamic environment which facilitates rapid prototyping/exploration and a static environment which supports development of high performance/quality products. This dilemma forces redundant development (first dynamic, then static) or use of only static environments, reducing productivity and increasing cycle time.
Due to the lack of domain-specific support, most applications are still developed in the traditional coding technoque. The fast expanding software buisiness has introduced many new dimentions of applications; so that software devlopers are now not limited to traditional professional programmers. People want a language and visual interface in their own problem domain. The exsiting domain-specific development tools are limited to a few areas such as graphic user interfaces, simulation systems, and CAD applications. People in different domains are isolated by different languguages and communications becomes ver difficult.
Transframe is designed to eliminate these obstacles.
Transframe has a type system that offers a transformable framework either freezable in dynamic programming system or meltable in static type system. Transframe enables MagicFrame to support dynamic typing provided by a dynamic language. Meanwhile, It also enables a software product finalization to have the size and speed to the equivalent product developed by traditional static languages.
By Transframe, classes (functions are unified into classes by Transframe) are first-class objects. They can be manipulated at run-time. New subclasses and new functions can be created at run-time with run-time values. With dynamic class management, classes created at run-time can be modified without rebuilding.
A class can be either in dynamic or in static state.
When classes are in static state, their instances and methods are represented in an efficent static code. They cannot be modified at run-time.
A system can extend a static class by defining new dynamic subclasses at run-time. Classes created at run-time are dynamic classes. A dynamic class is created on the base of a number of static classes or other dynamic classes. The extended part of the class hierarchy is dynamic class hierarchy. Both dynamic classes and dynamic class hierarchy can be modified at run-time.
A static class can be melted into dynamic class when a change is required. When class A is melted, any static subclass of A will be melted also. The class information generated by the compiler will be loaded from a semantics database to construct an associated dynamic class structure. Any access to a melted class from the client (either a static or a dynamic class) will be typed checked at run-time.
A dynamic class can be frozen into static class by on-spot code generation, compilation, and dynamic link and load. When a dynamic class A is frozen, any dynamic superclass of A will be frozen also. The class information will be generated by the compiler and stored in a semantics database. Any static client that have access to frozen classes will be recompiled and typed checked at compile-time to ensure correct usage.
The Transframe freeze/melt mechanism differs from other dynamic programming systems which require creation of two separate solutions, a prototype, which is thrown away, and a product. Magicframe is an integrated environment where the system evolves to maturity from prototype to product.
The Transframe freeze/melt mechanism is also different from other static programming environments which use an interpreter and an incremental compiler. The term freeze and melt is also used in Eiffel programming system to express a different concept: the written code can be melted into edit mode for modification and then frozen to running mode by compilation for testing. This requires a frequent melt-modify-freeze-test cycle in development. The Transframe freeze/melt is a language concept: a static type can be melted into dynamic type for redesign and a dynamic type can be frozen into static type for product deployment. Frequent melt-modify-freeze-test cycle is not required in a development phase. Modification and test can be conducted simultaneously in a dynamic programming environment. Transframe establishes a different cycle: melt-redesign-freeze-release, which significantly reduces the cycle time for developing next generation products.
We cannot equipt a language with miscellaneous built-in features for all possible high-level computing models such as Ada's task, SR's distributed resource, JAVA's synchronized method, ROOM's communicating object, and SmallTalk's persistency, making a super hodge-podge language.
Instead of providing domain specific computing models exhaustively, Transframe provides a transformable abstraction vehicle that can be adapted into various high-level computing models for diverse application domains. Such diversity is obtained from simplifying the fixed and built-in part of the framework; so that the user-definable part becomes larger and the framework are flexible enough to build various high-level models for applications like multi-thread tasks, active object with communication ports, event-driven model, distributed client/server models, mobile objects, data-driven models, etc.
The concept of function is integrated into class; so that the traditional concept of a function call is generalized to object instantiation. The semantics of object instantiation is user-definable; so that various specific function call protocols can be specified by the language user, for example, thread creation, remote procedure call, and communication through messages.
Classes can be nested. Member functions in C++ is integrated with nested classes. They are all member classes, which specify the capability of an object to spawn its component objects at run-time. A C++ member function call is equivalent to create a function object (a dynamic member object) within the enclosing object to perform a given activity; and after the member object finishes its duty, it is deleted, and an output object (if any) is returned as result. The semantics of Transframe's dynamic member object creation is much richer than C++ member function call. Since the protocol of object creation is user-definable, for example, features like slot provided by dynamic programming languages can be implemented as a member class. By member class inheritance, user can create various well-structured high-level computational models such as multiple thread task, active object with communication ports, distributed server with remote services, etc. These models provide various frameworks enabling developers to write their applications in their own native expressions as if they were using their own domain-specific language.
Another major unification is that the concept of object reference is integrated into the class concept; so that traditional concepts of constant names, variable names, and pointers are generalized to referential objects, which opens a door for various high-level object storage models such as leak-free dynamic object storage, persistent object depository, distributed object bank, etc. With smart references, languages like Java and Eiffel provides a memory-leek-free programming environment. With Transframe's generic referential frameworks, we get a resource-leek free (not limited to memory) programming environmnet.
Built around Transframe, the environment provides various high-level computing models and visual proggraming interfaces in the form of application frameworks. Unlike existing application frameworks wrapped in an unfitting box, for example, Taligent framework in C++ templates, Transframe application frameworks are represented in their fitting architecture. Application developers will always use their own native model to describe what they are going to develop as if they were using their own domain specific language. Most developers can create their applications by simple drap & drop actions with a visual design interface.
Transframe provides alternatives for users to chose features; so that costs selected to space, speed, and safety can be varied, depending on the required degree of flexibility in final products. Transframe's type system provides a possibility for compiler and linker to separate the class code from the object code. The class code is used for class property description. It is separated further into simple class code and complete class info. Simple class code contains basic information about a class, which is used for dynamic binding, and is similar to C++ virtual function table in a more general sense. It is compiled into a separate linkable module and linked into the running system only when it is used. Complete class info contains the complete semantic information for a class which is used in dynamic programming environment. It is stored in a semantics database and loaded into the running system by a dynamic class management system.
If applications do not use any polymorphic features, the final executable code is generated from the pure object code. The size and speed of the code can be byte-to-byte equivalent to that developed by traditional languages like C.
If applications use polymorphic features for flexibility, the linker will link only those related simple class codes into the final executable, i.e. the class code is linked into the application only if the class is used by a polymorphic variable. The class code is similar to vtable in C++ implementation. The size of the executable code is about the same of that generated by C++ compiler.
Some large applications, such as distributed systems, application development tools, and database applications, need a more powerful dynamic class manipulation. Transframe programming environment provides various dynamic class management systems and uses complete class information stored in the semantics database for the static code. You can freeze the code as much as you want while remain some part of the system dynamic for customers' configuration or third-party development.
Sitting between the powerful dynamic typing system and the efficient static typing system, dynamic parametrism is provided for efficient dynamic typing. Dynamic parametrism provides a dynamic derivation of subclasses from a generic superclass. Compared to traditional dynamic typing system, it encourages prefabricated framework; so that type-errors can be detected early at compile-time. Dynamic binding of a class parameter can be implemented efficiently by an indirect link, which is equivalent to C++ virtual function implementation. Compared to traditional static typing system, the generic framework can be customized at run-time, i.e. new subclass can be derived at run-time for dynamic typing, which is useful for plug-and-play architectures that require dynamic configuration.
Transframe is intended for writing programs that must be reliable in a variety of ways. The final compiled product code in a static environment is free of run-time type errors. Local type checkability is preserved to allow modular compilation. It supports protocols for leak-free resource management, for instance, leak-free dynamic memory management with garbage collection. Unlike other languages, protocols for leak-free resource management are not built-in language features. Transframe provides a generic framework for users to build various those protocols.
A type error is a violation of the semantics of a name when an object is bound to the name. A type error occurs when a name is declared to represent an object of type C but actually it is bound to an object of type S which is not compatible to C. If there is such a possibility at run-time, the system is not statically type safe. A statically type safe system should detect all possible type errors in a program and when a system is generated from the program, it is guaranteed type-error free.
Transframe reports all type errors during separate compilations. Either at the time of link or at run-time, there will be no type error reported. In the dynamic programming environment where dynamic classes has not been compiled (frozen) yet, the system will check the usage of a dynamic type and guarantee the validness of an access.
During compilation, any code that would cause a type error shall be rejected unless type assurance statement is used. Compiled code shall be type-error free. Type assurance statement can be eliminated by type inference during optimization.
Due to the precise expression in type dependency, Transframe reduces many chances that would require run-time type checks by other static languages. Run-time type check or system level verification is not required for final applications running in close world assumption.
Compared to C++ and Java, a Transframe program is safer. Type information is available whenever it is required. Features like variable number function inputs and object slicing that are unsafe in C++ are safe in Transframe. Transframe supports development of various resource-leak free protocols. Dangerous C-style pointer arithmetic is strictly limited. Thanks to the capibility of type-dependency specification, the frozen Transframe code requires much fewer run-time type checks than Java and do not reports run-time type exceptions at run-time.
Compared to Eiffel, Transframe provides a type system where type-dependent covariance is safely described. Covariance is a common and useful case that requires to specialize the type of an argument in a subclass. Transframe provides a better description than Eiffel; so that system-level type check is not required and error isolation is guaranteed. Transframe reduces the necessity of dangerous type castings, which would be required by other languages like C++ that does not support covariance.
Interface specification among software components is more precise than that provided by other typed languages. It describes the type dependency among input and output objects, and among enclosed and enclosing objects. Interface users are less likely to get unexpected error report due to a misuse of a function.
Transframe provides interface classes that hides information to clients who have no right to access it. An interface class can be used as in an IDL (interface definition language). A class can have different interfaces which are exposed to different groups of users.
In order to make the language more comprehensible to the majority of the embedded/real-time software engineers, the syntax of Transframe is designed as closely to C++ as possible.
Instead of bringing about brand new concepts, Transframe provides a natural extension to the ordinary concept of class that have been commonly used by other popular object-oriented programming languages. While generalized, concepts are also simplified by unification. For example, functions are classes; nested classes and member functions are member classes (In C++, the semantics of a nested class is not well defined and is fundamentally different from a member function); and function call is object instantiation. Classes are the only concept of the language.
Transframe expression looks very similar to C++, but simpler. Very few exceptional rules are used to construct a Transframe expression. There are only two kinds of expressions: primitive expressions and compound expressions. The number of BNFS rules for expression are just about 10.
The power of flexibility lays on the simplicity. While any form of C++ expressions can be imitated by a Transframe expression, Transframe offers a much richer expression in terms of user-definable operators, heterogeneous list constructors and array constructors, flexible operator formats, safe variable number of input arguments, type expressions, and expressions close to nature language. Transframe enhances many poorly understood and confusing C++ operator overloading definitions such as function call operator and new operator.