Deepin Open Source Community has previously announced its self-developed programming language - Unilang on Github and gitee, and also includes related interpreters, explaining Unilang documents and reference implementations Way.
The official description in the library is "new programming language", which is "a proposed general-purpose programming language project to adapt to more efficient and flexible development of desktop environment applications", which aims to better help current desktop application developers. The host environment is MSYS2 MinGW32 and Linux.
Judging from the Demo source code, the Unilang language does not seem to be too difficult.
"Hello world demo."; puts "hello, world";
According to reports, because some of the most popular standardized languages such as C / C++ and ECMAScript have heavy historical burdens, and do not have the ability to expand the language itself to take into account its needs; Dart and other languages designed for similar solutions are in some basic design decisions (such as relying on global GC) prevent it from being fully suitable for some important scenarios; other general-purpose languages, such as Rust and Go, do not come with a GUI solution.
Therefore, they hope to bring a new language based on the need to meet the needs, so that it can achieve true generality in a deeper way - by reducing the native ad-hoc (ad-hoc) prepared for individual problem domains. -hoc) feature and replace it with a more general set of basic features.
Unilang is designed to coordinate the language part of the new solution to solve the existing deficiencies. The main features are: As a dynamic language, it provides stronger scalability at the language level than other languages. Through the function of user-defined language, unexpected dynamic characteristics can be effectively limited, and finally the advantage of development experience close to that of most static languages can be obtained, and the inconvenience caused by the core rules of static language can be avoided at the same time. Allows the addition of libraries to complement existing language features in environments where Unilang programs have been deployed without redeploying the toolchain implementation. Provides a base language and extends this language in the form of a library with a useful feature set. Libraries are expected to be provided by this project and by users. In most languages, the features provided by the core rules of the language need to be modified. In Unilang, it is expected that only the library written in the Unilang language needs to be solved by the user. For example, static type checking can be provided by the user program. Like C and C++ and unlike Java, no specific form of translation and execution is explicitly required or assumed. Implementation details such as compilation, interpretation, and what image format to load are transparent to the core language rules. Does not presuppose explicit phases of translation as in C and C++. Macros that don't require a separate stage expansion - can replace macros with functions that support first-class environments. Homoiconicity is supported, allowing code as data programming. Functions are first-class objects. The environment takes ownership of variable bindings. Support first-class environments as first-class objects. Supports a C++-like object model and (currently unchecked) unsafe ownership semantics. Unlike C# or Rust, etc., there is no special unsafe keyword to mark "unsafe" code paragraphs, and the most basic features are "unsafe" by default. Security is not uniquely defined by the language, allowing users to implement custom different kinds and degrees of security by extending the type system, etc. Global GC is not required, and a subset of the language allows the same level of "unsafe" as C++ but ensures deterministic resource allocation. No static checking for unsafe operations is provided natively, but the extensibility of the language allows for direct implementation of the type system or automatic proof of stronger memory safety. It may be provided as a library in the future. Language rules still allow the introduction of GC-dependent interop. In particular, multiple non-global GC instances are allowed to be introduced. Supports PTC in the formal sense without requiring workarounds in user programs for undefined behavior such as stack overflows. In mainstream languages, no language implementation that does not rely on global GC provides similar guarantees. Use implicit latent typing instead of explicit manifest typing. Before the extension, as an implementation detail, implied type inference was allowed to eliminate some type checks without affecting program semantics. Allows user programs to extend the syntax and related checks of type annotations. This naturally avoids conflicts between user-extended type systems and native rules, while maintaining extensibility. An expression is a similar but slightly different value category to C++; but unlike C++, it is not a statically determined property of the expression, but follows the dynamic metadata of the object. Similar to C++'s const type qualifier, objects referenced by lvalue are allowed to be marked as immutable (read-only), rather than the default convention of languages such as Rust to be immutable (immutable). Similar to C++'s demise value (xvalue), an object referenced by an lvalue allows the tag to be unique and the resources within it to be transferred. Principles A common approach in the above representative selection decisions is to compare the technical feasibility of expansions in different directions—and to choose the option that is easier to expand. Otherwise, even if feasible, there is a lot of ineffective work that should be avoided. Therefore, the language requires PTC in the first place to make its implementation sufficiently usable without encouraging nested unreliable implementations. Note that unreliable implementations of PTC may still be successful in other ways (eg Babel translating ECMAScript dialects). As such, most other features do not (and need not have) the status of an explicit guarantee of the ground rules such as the PTC. Therefore, the language first excludes reliance on global GC. For example, in languages marked "unsafe" with ad hoc syntax such as unsafe, it is common to waive any language-defined safety guarantees, with no option to keep some of them. Even ignoring this issue, the language lacks a mechanism to allow users to provide stricter guarantees. For another example, the default immutable data structure can guarantee "correctness" such as const correctness (a type safety (type safety) that keeps the limited immutability property from being discarded), but ignores the "immutability". The definition of 's does not adequately describe the problem of allowing user programs to extend - in many cases, immutability simply needs to be an equivalence relation, not immutable. Therefore, the base language is insecure by default. If the language allows users to express "some values with different representations are considered equivalent", the adaptability of the optimization naturally expands. This implies that there is only one kind of immutability, unless the type system design is modified to drop the original immutable definition and reintroduce a C++ const-like qualifier mechanism (the "harder" case). Here, using an unsafe cast like const_cast to cancel the type safety guarantee introduced by const and assume that it doesn't break immutability is a helpless workaround (the "harder" case, and less effective without restoring type safety). This can lead to concrete immutability being abused, e.g. the key type of the C++ standard library associative container does not actually need to conform to C++'s const, because the immutability of the key is exactly defined by the equivalence relation derived from the comparison relation, but the type system cannot Distinguish the two situations. This overly restricts what should be allowed on the key. Default immutable type systems, like Rust's design, more fundamentally prevent the direction of extension on type composition constructs. This also limits the optimization scope of the existing implementation of const propagation, because in principle the "constant" here only cares about the replacement to maintain the semantic-preserving before and after the transformation (semantic-preserving), and does not care about the specific Are the values equal. Therefore, objects in the base language are mutable by default. Therefore, the base language was first designed to be a dynamic language. Designing a static language and then adding some rules to disguise it as a dynamic language with sufficient dynamic features is far more difficult than adding rules to a dynamic language to get the feature set of a static language. Adding a proof to restore a guarantee (without conflicting with other guarantees) from a context that marks a waiver of a guarantee is more difficult than adding a proof to ensure a guarantee from a context that is known to have no guarantees. To exclude GC in a language that already requires global GC is far more difficult to add the ability to interact with GC on the basis of language rules that do not depend on GC (especially when GC allows user customization). Adding extensions to a language implementation without PTC guarantees is basically infeasible, unless the logic including the core evaluation rules is reimplemented (eg, by adding another execution engine). It has good interoperability with C++. The current interpreter (runtime) is implemented in C++. Combined with the object model, the correspondence between Unilang objects and C++ objects can be ensured. Language bindings focus primarily on C/C++ APIs with known ABIs. In order to maintain generality, Unilang does not provide GUI functions built-in, but provides related APIs through libraries. In the current plan, Unilang will support Qt-based binding libraries in order to bridge some existing desktop application projects. Unilang's language design remains sufficiently abstract and extensible to allow direct implementation of GUI frameworks in the future.