unilang Goto Github PK

A universal programming language

Unilang is a programming language and IDE. It has a graphical and textual fronted for creating programs. The language unifies with other languages through transcompilation. It was written to improve the quality of software by allowing a paradigm of rich data annotation. It was also designed to make developing software more interactive. This diagram shows the transcompilation process from a compressed GUI format to traditional source code.

Despite their name, general-purpose programming languages (GPLs) become associated with specific niches that target particular programming domains. Due to the differences between these languages (both internal and external to their design), evaluations on the problem space lead to different languages being chosen. A cross-domain problem is then solved through a mixture of languages. Under such circumstances, individual GPLs have not proven general enough as the solution to the entire problem space. Unilang's stance is that the amalgamation of different languages could be an implementation detail below a more conceptually pure representation of the full problem ontology. We consider different languages within the same ontology to be less productive for establishing insight and enabling code evolution. It is better to have the entire problem space of software encoded from the same unifying model, otherwise system-wide reflexivity becomes untenable. A unifying language can operate as a transcompiler to other existing GPLs as needed. In fact, this text was written in Unilang. Whether you're reading it in markdown, html, pdf, or something else, it originated from the same language model.

The creation of this language is different from traditional programing languages because it rejects using lexical analysis for syntax conformance and language grammars for semantic conformance. The solidification of a language frontend can be achieved without tokenization toward gramatical AST construction. Programming in Unilang is the declarative encoding of concept values to a language's meta-model. This avoids the typical transformation process where syntactical expressions are parsed into ASTs; a strategy that seems to lose the pragmatic meaning from the originally intended encoded information. An example of this issue can be more widely seen if we reflect on the usefulness of compiler errors. A large amount of effort has gone into trying to make error messages as clear as possible, but often times there still remains a clarity gap that could be filled. By any means, why should the programmer be capable of making syntactical mistakes in the first place? Projectional editing can solve this. A longer description for the rationale around Unilang's design is covered in the remaining subsections.

Unilang is a universal programming language (UPL). A UPL has not been formally defined prior to this document, but as an informal definition, envision a UPL as a language abstraction over GPLs and IDLs. It's a high level Universal Computer Oriented Language (UNCOL). UPLs are a universal encoding for developing software. In this case, Unilang is also a visual programming language (VPL).

Creating a language that could properly be the right choice for every programming domain sounds impractical. Domains can have opposite requirements. Trying to encode everything necessary for all domains would result in something so complicated, contradictory, and convoluted that it would defeat the purpose it set out to accomplish. It would become too difficult to use in any domain. These concerns are valid, and maybe even inevitable. We acknowledge them here as they have been influential in Unilang's design. If Unilang were built in the traditional way that GPLs are, we would certainly hit many of these problems. We instead take different approaches toward a language's role in facilitating software development. Unilang is an experiment to challenge these concerns and to try and innovate ways around them.

The unilang model begins with a set of signifiers whose values represent paths. . Through path interpretation, a schema-enabled tree is formed and this enforces the parent-child relationships. When the tree is modified during projectional editing the user will not be able to mutate into an invalid tree. The abbreviations "pk" and "fk" correspond to primary and foreign keys to allow association between subtrees. This is a similar concept found in ERDs and databases.

The IDE can be used the following way.

git clone [email protected]:luxe/unilang.git
cd unilang
./user_run_optimized //code/programs/ide:main

Various CIs are used to test the correctness of the build. Referencing these builds may help you acquire any additional dependencies. The reason we use multiple CIs is to ensure a general consensus and catch any outlying issues. However, these services have limitations at their free tier, and so full builds/tests are not performed.

Continuous Integration	Status	Notes
App Veyor		Bootstraps Build
Circle		Bootstraps Build
Cirrus		Bootstraps Build
Codeship		Bootstraps Build
Drone		Bootstraps Build
Scrutinizer		Bootstraps Build
Semaphore		Bootstraps Build
Shippable		Bootstraps Build
Travis		Bootstraps Build

Please contribute. Make a ticket about anything.