Text-Oriented Compiling
In text-oriented development, the process of producing binary executable files from source code is not the job of a stand-alone, closed program called ”compiler“. There are no fixed, stand-alone strings called ”source files“, either. Instead, there is a single parsed text structure that contains several layers describing the software product that is written in several languages. There are prose writings such as a goal description, requirements, discussion messages between team members, there are formal writings such as specification and design documents, there are one or more layers in programming languages, and at the bottom there is an assembly language layer.
Software Source Structure
The software source is a parsed text structure that consists of text units with relationships among them. An e-mail is a text unit consisting of a string text unit having the subject and a prose text unit having the message. A code function is a text unit consisting of a signature text unit and a body text unit. The function body text unit consists in turn of some text units as the result of its syntax analysis: an if-unit, a for-each-unit, etc. An assembly instruction text unit consists say of an operation plus a parameter, being both again text units.
There are dependencies between units. For example: one took a decision in an e-mail after a discussion, as a consequence a line of a function must be changed. This dependency is recorded at the repository. A dependency can be bound to a text transformation operation that describes how to get the target unit from the source one. Some of these transformations are executed automatically, others manually. They can be just a hint of what to do such as ”test it“, a procedure description in prose or in a script language, or a complex program.
Compiling
The last layer of a software artifact is the assembly layer. That is the complete representation of the product by means of assembly language for a particular processor architecture. The assembly layer integrates with the rest of the text repository. It is not inflexibly generated by a ”compiler“, some parts of it may be automatically generated and some other parts handcrafted. It can consist of more than one layer, for example a generic one that is architecture-independent and some architecture-specific modules.
In a text-oriented environment one can still call ”compiler“ a software piece than generates assembly code by transforming units written in a particular programming language, or, more accurately, units having particular semantics. Such compiler is not a program that runs on some ”source files“ and produces ”executable files“, it is a program that receives a text unit as input, transforms it, and gives a text unit back. Generating a program is not calling one compiler once, but letting the system transform one text unit once, being the system responsible for invoking all needed compilers on the required units that compose it.
Such a compiler does not parse source code, of course. It does not get character strings as input, but already parsed text that it can navigate and query.
You may be asking: ”but what about the actual executable files?“ Well, executable files are just a particular representation of assembly text units. Once you get the assembly text, you can always export it as binary file.
