Storing program source as relations in a database instead of text file

[FactChecker]

The interesting advantages cited in the OP are that you can:

• follow the relations and enforce the rules before compiling
• automate certain processes (ex.: if function A is used, called library X)
• study relations in complex programs more easily
• let programmers choose their own language (or maybe even their own grammar; you could choose that an expression is ended by a semicolon or a new line) when converting from/to a human-readable text file (maybe even reading/writing flow charts)
• etc... (as I'm basically restating the OP)

It doesn't affect the speed of programming as, in the end, the SQL file must still be compiled to a binary file to be executed.

My main complaint is that it seems to suppress the order of execution, which I feel is usually the primary information in the code text. And if the sequence of execution is the main "sort order" in a database, I don't know if I would still call it a relational database.
Of course, it is still possible to build relational databases that are used as part of the compilation process. For all I know, that may already be done.

 

[jack action]

it seems to suppress the order of execution, which I feel is usually the primary information in the code text. And if the sequence of execution is the main "sort order" in a database, I don't know if I would still call it a relational database.

The order of execution wouldn't be different. It is about how the information is stored (which includes the order of execution).

Imagine each library stored as a database. Looking for information through the different libraries is much easier and can be done in a million different ways. You can find easily in a project if a library (database) is not used anymore. You may easily search a library that you already have for something you want to execute, instead of loading (or creating) a new library. You don't look for text (which could be written in a million different ways), you look for relations.

The 'relational' lies in the storage, not in the execution.

Of course, it is still possible to build relational databases that are used as part of the compilation process. For all I know, that may already be done.

What the OP says is: «Why not save the programs as those relational databases instead of the original text files? Much likely the file sizes and the compilation time will be smaller and the access to information will be more flexible.»

 

[Mark44]

Imagine each library stored as a database.

This is already done with compiled languages like C and C++. The database has the form of a lookup table whose keys are the function names (C) or function signatures (C++). Associated with each function name/function signature is the compiled machine code for the function.

Looking for information through the different libraries is much easier and can be done in a million different ways. You can find easily in a project if a library (database) is not used anymore. You may easily search a library that you already have for something you want to execute, instead of loading (or creating) a new library.

There already are tools and techniques that can be used to determine which functions a library exports, so I don't see how the suggested changes do anything that isn't already done.

You don't look for text (which could be written in a million different ways), you look for relations.

For the compiled languages I'm talking about, the library (either a static library or dynamic link library) doesn't contain text -- it contains just the machine code associated with the functions plus any other objects that the library exports.

 

[FactChecker]

The order of execution wouldn't be different. It is about how the information is stored (which includes the order of execution).

So, would the order of execution be stored as a number in some of the entries, or as a pointer to the next line to execute, or what? IMO, it would not be a relational database because the most important information for execution is stored as a linked list. It just seems hopelessly confusing and hard to interpret to save such information that way.

 

[suremarc]

A friend of mine used to work at NYSE. The lead software architect there (his name is Alexei Lebedev) created a system that generates what is essentially a zero-overhead in-memory database in C++. You define your data in the form of tabular relations, and it knows how to generate efficient code for algorithms and data structures from it. I have not used this system myself, but from what I have heard they use it extensively to encode highly cross-referenced data types as well as business entities (for example, other exchanges and their attributes, e.g. MIC’s), and case-driven testing.

An open-source implementation can be found at github.com/alexeilebedec/openacr. Even if you are not going to use it, I think the problem it attempts to solve is interesting and the author wrote a decent amount explaining his rationale. I recommend the read.

 

[Jarvis323]

Summary:: Most programming languages and environments store program source as text in source (and accompanying) files. But a program can be seen as a collection of relations between different objects, and thus these relations could also be stored in a data base. For example: every Variable has a relation to a Type, every function call implies a relation between caller and callee, etc. Has there ever been an attempt to store program source in the form of relations into a database?

Almost all (compiled or interpreted) programming langues store the program source in the form of a series of bytes (using an encoding like ASCII or UTF-8) into a text file, enforcing the grammer of the programming language using a parser (as part of the compilation process or interpretation of the source text).

But intrinsically a program can also be seen as a collection of relations between different objects, which can be stored as tuples in a relational database system.

For example:

• A program Variable needs to have a definition, which creates both a relation between the variable and a type, and also a location within another object (for example a function and/or module) in which the definition takes place.
• A function call creates a relation between the calling function or module and a called function, a relation between its return value and a type, and a relation between the function and the object or module in which it was defined.

Etc.

No programming language or environment (perhaps with the exception of a language/programming environment like smalltalk) however stores these relations as such, most languages store it as text in a source file.

The advantages of storing program source as relations in a database are multiple, like for instance:

• One can enforce strong typing rules for all objects.
• One can produce many usefull insights into the program source, like dependencies between objects (what function gets called by what function, what modules or objects use what variables, etc.).
• Compilation could be done piece wise (per object) as part of the editing proces (saving the object also pre-compiles it, and shows the errors encountered during compilation if any - source is stored anyway).
• Each variable or object name needs to be stored only once, and renaming objects would only take place at one point. Optionally, each programmer could name objects in their native language and script.
• The program itself can be stored in the form of an abstract syntax tree, simplyfying the process of creating object code and executable generation.
• Refactoring a program, or moving functions between modules, and retaining all dependency relations (like header files), could be done much simpler and less error prone then in a textual environment.
• Build/make information can be easily extracted from the relations already stored in the database, using the dependency relations already stored.
• Optionally also the versioning system itself could be implemented as part of the programming development system, also storing version information as relations into a database.
• For compatibility with the usual work environment and programming development tools, easy import and export functionality could be provided for such a programming development environment.

I guess it's probably not exactly what you're thinking about, but logic programming languages are based on sets of relations, with prolog being a good example.

the program logic is expressed in terms of relations, represented as facts and rules. A computation is initiated by running a query over these relations.

https://en.m.wikipedia.org/wiki/Prolog