Shulou(Shulou.com)11/24 Report--

Thanks to CTOnews.com netizens grass Luo Yuzi, lonely snail for the delivery of clues! CTOnews.com, September 12, some CTOnews.com netizens found that the deep open source community had previously announced its self-developed programming language, Unilang, on Github and gitee, as well as related interpreters, explaining Unilang documentation and reference implementation.

The official description in the library is "new programming language", which is "a general purpose programming language project proposed to adapt to the development of desktop applications more effectively and flexibly", which aims to better help current desktop application developers, hosting environments such as MSYS2 MinGW32 and Linux.

Judging from the Demo source code, the Unilang language doesn't seem to be too difficult.

"Hello world demo."

Puts "hello, world"

According to reports, the depth team has a heavy historical burden on some of the most popular standardized languages such as C / C++ and ECMAScript, and does not have the ability to extend the language itself to meet its needs; languages such as Dart, which are specially designed for similar schemes, make basic design decisions (such as relying on global GC) that are not fully suitable for some important scenarios. Other general purpose languages, such as Rust and Go, do not come up with GUI solutions.

Therefore, they hope to bring a new language on the basis of meeting the needs, so that it can truly achieve versatility in a more profound way-by reducing the native ad-hoc features prepared for individual problem areas and replacing them with a more general set of basic features.

Unilang is designed to co-ordinate the language part of the new solution to address existing deficiencies, with the following main features:

As a dynamic language, it provides stronger extensibility at the language level than other languages.

Through the function of user-customized language, we can effectively limit the unexpected dynamic characteristics, and finally get the advantage of development experience similar to that of most static languages, while avoiding the inconvenience caused by the core rules of static language.

Allows existing language features to be complemented by adding libraries in environments where Unilang programs are deployed without the need to redeploy the implementation of the toolchain.

Provide a basic language and extend the language in the form of a library to get a practical feature set. The library is expected to be provided by this project and users.

The features provided by the core rules of the language need to be modified in most languages, and it is expected in Unilang that only libraries written in the Unilang language are required, such as static type checking, which can be provided through user programs.

Similar to C and C++ but different from Java, it does not explicitly require or assume the specific form of translation and execution. The implementation details such as compilation, interpretation and image format loading are transparent to the core language rules.

There is no definite translation stage (phases of translation) such as C and C++. Macros that do not need to be expanded in separate phases can be replaced by functions that support a first-class environment.

Support homoiconicity, allowing code-as-data (code as data) programming.

Function is a first-class object (first-class object).

The environment has ownership of variable bindings. First-class environment (first-class environment) as a first-class object is supported.

Support for an object model like C++ and (currently unchecked) unsafe ownership semantics.

Unlike C# or Rust, there is no ad hoc unsafe keyword tagging "unsafe" code paragraphs, and the most basic feature is "unsafe" by default.

Security is not uniquely defined by the language, allowing users to achieve different kinds and degrees of customized security by extending the type system and so on.

Global GC is not required, and a subset of the language allows for "insecurity" at the same level as C++ but ensures deterministic resource allocation.

There is no native static check for unsafe operations, but the extensibility of the language allows you to implement a type system directly or automatically demonstrate greater memory security. It may be provided as a library in the future.

Language rules still allow the introduction of GC-dependent interoperability. In particular, multiple non-global GC examples are allowed.

Support PTC in a formal sense without the need for modifications to undefined behaviors such as stack overflow within the user's program.

In mainstream languages, language implementations that do not rely on global GC do not provide similar guarantees.

Use implicit latent types (latent typing) instead of explicit list types (manifest typing).

Before extending, as implementation details, implied type inference (type inference) has been allowed to eliminate some type checking without affecting program semantics.

Allows user programs to extend the syntax and related checks of type tagging (type annotation).

This naturally avoids conflicts between the user's extended type system and native rules, while maintaining extensibility.

Expressions are similar to C++ but have slightly different value categories (value category); but unlike C++, they are not statically determined properties of the expression, but rather follow the dynamic metadata of the object.

Similar to C++ 's const type qualifier, objects referenced by the left value are allowed to be marked as immutable (read-only) instead of the default convention value immutable (immutable) for languages such as Rust.

Similar to the extinction value (xvalue) of C++, objects referenced by the left value allow the tag to be unique and the resources in it to be transferred.

Among the representative selection decisions above, a common approach is to compare the technical feasibility between extensions in different directions-and to select options that are easy to expand. Otherwise, even if feasible, there are many ineffective jobs that should have been avoided.

Therefore, the language first requires PTC to make its implementation sufficiently available, rather than encouraging nested, unreliable implementations.

Note that unreliable implementations of PTC may still be successful in other areas (such as translating Babel in ECMAScript dialects). Therefore, most other features do not have (and do not need to have) the status that PTC requires an explicit guarantee from the basic rules.

Therefore, the language first excludes the dependence on the global GC.

For example, in languages marked "unsafe" with ad hoc syntax such as unsafe, it is common to abandon any security guarantees defined by the language and not choose to retain some of them. Even if this problem is ignored, the language lacks a mechanism that allows users to provide stricter guarantees.

For another example, although default immutable data structures guarantee "correctness" like const correctness (a type safety (type safety) that keeps qualified immutable properties from being discarded), it ignores the problem that the definition of "immutable" is insufficient to allow user programs to expand-in many cases, immutability only needs to be an equivalent relationship, not immutable.

Therefore, the underlying language is not safe by default.

If the language allows the user to express that "some values with different representations are considered equivalent", the adaptability of optimization will naturally expand.

This implies that there is only one kind of immutability unless the type system design is modified, the original immutable definition is abandoned, and qualifier mechanisms like C++ const are reintroduced (in the "more difficult" case).

It is a helpless workaround here to remove the type safety guarantees introduced by const with unsafe conversions such as const_cast and to assume that immutability is not broken ("more difficult" cases where type safety cannot be restored and less effective).

This may lead to the abuse of specific unmodifiable, for example, the key type of the C++ standard library association 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 comparative relationship, but the type system cannot distinguish between the two cases. This excessively limits the operations that should have been allowed on the key.

Type systems that are immutable by default, such as the design of Rust, more fundamentally block the direction of extension in type composition constructs.

This also limits the scope of constant propagation (const propagation) optimization for existing implementations, because in principle the "constant" here only cares about substitution maintaining semantic equivalence (semantic-preserving) before and after transformation, not whether specific values are equal.

Therefore, objects in the underlying language are mutable by default.

Therefore, the basic language is first designed as a dynamic language.

Designing a static language and then adding some rules to disguise it as a dynamic language with sufficient dynamic characteristics is far more difficult to add rules to the dynamic language to get the feature set of the static language.

Adding a proof to restore a guarantee from the context in which a tag waives a guarantee (and does not conflict with other guarantees) is more difficult than adding proof to ensure a guarantee from a context that is known to have no guarantee.

Excluding GC from a language that already requires global GC is far more difficult to add the ability to interact with GC on top of language rules that do not rely on GC (especially if GC allows users to customize).

Adding extensions to a language implementation that is not guaranteed by PTC is basically not feasible unless logic including the core evaluation rules is reimplemented (for example, adding an execution engine).

And C++ have good interoperability.

The current interpreter (runtime) is implemented using C++.

Combined with the object model, we can ensure the correspondence between the Unilang object and the C++ object.

Language binding mainly focuses on the C / C++ API of the known ABI.

To maintain versatility, Unilang does not provide GUI functionality built-in, but provides related API through the library. In the current plan, Unilang will support Qt-based bound libraries to bridge some of the existing desktop application projects. The language design of Unilang maintains sufficient abstraction and extensibility to allow direct implementation of the GUI framework in the future.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.