Nimskull (eventually Cyo)

The Nimskull compiler, stdlib, tools, and documentation repository.

Code of Conduct · Code of Ethics · Documentation

About the Project

The Nimskull (temporary name) compiler, stdlib, tools, and documentation repository. Nimskull is starting off as a derivative Nim, with the intention of becoming a different language called Cyo.

The goal is to have a statically typed structured programming language to create software (including itself) that is sustainable, it aims to be:

• Safe: statically typed, nil safe, with structured approach to resources and concurrency
• Scalable: target a variety of hardware architectures, with zero or low cost abstractions to run in constrained environments.
• Adaptable: producing native executables, running via the built-in VM, or using a JS runtime.
• Evolving: developed and maintained by its community of users, with a self- hosted compiler, support for metaprogramming to safely attempt language extension outside of the core, and support code migration to avoid legacy.

We are currently working on the first phase of this, by slimming down the language and compiler to a workable core and increasing compiler development productivity. The following phase will starting with one of the following possible features:

• Introduce Continuation Passing Style transform and Structured Concurrency into the language, this will undoubtedly lead to dramatic changes in memory management and FFI
• Ease Data Oriented Design through memory regions to support the common handle instead of reference approach

Near-Term Development

For updates on the progress see the roadmap progress thread

The current and key areas of development are as follows:

1. improve tests - core specification as tests (see slim the core below). Reorganize existing tests. Project to track progress.
2. nkError/tyError/skerror - replace localError etc approach with an AST (nkError) one Project
3. comments - incrementally document compiler source for easier learning
4. slim the core - remove dialects, backwards compatibility, etc Discussion

There are more, the above have been carefully chosen based on the direction of the language; moreover, their impact goes beyond what's been described and intends to create a virtuous cycle. Examples:

• clarifying the language specification will identify bugs and design flaws that in turn will be fixed.
• changes introduced via nkError result in more pure code (func) as control- flow and effects are no longer intertwined; lead to bug and language design fixes due to a broad audit, ease compiler as a library usage for tools

(back to top)

Community

Currently, this repository and our matrix/irc are our primary community hubs; we'll introduce more as things grow. At this time our community is small but passionate and close. We welcome any who are able and eager to collaborate on improving the compiler and associated tools.

Check the FAQ, or Project Board for an idea of where to help.

There's plenty to be done, and we appreciate even the smallest contribution to documentation! We look forward to seeing introductions and pull requests!

(back to top)

Compiling

The compiler currently aims to support the following platform and architecture combinations:

• Windows (Windows XP or later) - x86 and x86_64
• Linux (most, if not all, distributions) - x86, x86_64, ppc64 and armv6l
• Mac OS X (10.04 or greater) - x86, x86_64, ppc64 and Apple Silicon (based on the ARM64 architecture)

More platforms will be supported, however, they are not tested regularly and they may not be as stable as the above-listed platforms.

Compiling the compiler is quite straightforward if you follow these steps:

Show

First, the C source of an older version of the compiler is needed to bootstrap the latest version because the compiler itself is written in the programming language. Those C sources are available within the nim-lang/csources_v1 repository.

Next, to build from source you will need:

• A C compiler such as gcc 3.x/later or an alternative such as clang, Visual C++ or Intel C++. It is recommended to use gcc 3.x or later.
• Either git or wget to download the needed source repositories.
• The build-essential package when using gcc on Ubuntu (and likely other distros as well).
• On Windows MinGW 4.3.0 (GCC 8.10) is the minimum recommended compiler.
• Nim hosts a known working MinGW distribution:
  • MinGW32.7z
  • MinGW64.7z

Windows Note: Cygwin and similar POSIX runtime environments are not supported.

Then, if you are on a *nix system or Windows, the following steps should compile Nim from source using gcc, git, and the koch build tool.

Note: The following commands are for the development version of the compiler.

git clone https://github.com/nim-works/nimskull.git
cd nimskull
./koch.py boot -d:release
./koch.py tools -d:release

Finally, once you have finished the build steps (on Windows, Mac, or Linux) you should add the bin directory to your PATH.

(back to top)

Contributing

Contributing is simplified thanks to our contribution guide. Right now, the easiest and most important contribution is test suite improvement, also described in the guide.

Koch

koch is the build tool used to build various parts of Nim and to generate documentation, among other things. The koch tool can also be used to run the Nim test suite.

Show

You may execute the tests using ./koch.py tests. The tests take a while to run, but you can run a subset of tests by specifying a category (for example ./koch.py tests cat lang).

For more information on the koch build tool please see the documentation within the doc/koch.rst file.

(back to top)

Direction

A language (community, compiler, etc) that is sustained through the collective efforts of its practitioners and their diverse backgrounds.

Attracting practitioners with diversity of experience and perspectives requires a language with broad applicability, from the Web to Systems Programming all the while remaining efficient.

Onboarding practitioners requires a language that is familiar enough to get started in terms of syntax and initial concepts such as structured and modular programming.

Supporting practitioner-driven innovation requires a language that allows for experimentation without necessarily being an expert in all aspects of language development. Compile time facilities integrated into the language, such as compile time evaluation and a macro system provide a sandbox.

Practitioner collaboration and combining collective efforts is assisted through logical contracts provided by a static type system that supports local inference, tuples, sum, and generic types, along with effect analysis.

A language that develops in such a manner is going to encounter what some might term as 'instability' via numerous backwards-compatibility breaking changes. We consider this a feature, instead we:

• favour designs (language or API) that are resilient in the face of change
• employ tools that automatically migrate legacy code or assist in migration
• not ossify poor choices and be honest that we can't make such guarantees

Popular languages are maintained through incredible amounts of funding from various entities; we do not see, nor seek, this happening for us. Alternatively, there are a number of languages that require unhealthy amounts of free labour from a few, we're not interested in that either. Instead as is described this language will focus on practitioners able to affect their tools and community.

(back to top)

FAQ

Why start with Nim?

It's convenient. Creating a compiler from scratch is labour intensive and the existing contributors are already familiar with the current code base. We chose to evolve it.

Will this break my Nim code?

This project aims to become a different programming language, so do not expect source code compatibility. If you want Nim then use it.

What's the rationale for this fork?

It's more a starting point and eventually the languages will have diverged so as to no longer being compatible.

What are you going to do now?

For the moment, please see our [projects board](https://github.com/nim-works/nimskull/projects) and [direction](#direction) for more information. We envisage great things; however, all great things come with time, and we have a large foundation that was never properly solidified.

Can I help somehow?

Presently we're very interested in people contributing; a good start is to help the "language spec as tests" effort which is being led by @haxscramper. If you're willing to dive deeper into the compiler then see the "nkError refactor to make the compiler approachable" project.

Any chat room on matrix/irc/discord?

Yes! Feel free to join us on our [nim-works channel!][nim-works-matrix] Please have a read of our [Code of Conduct](https://github.com/nim-works/nimskull/blob/devel/CODE_OF_CONDUCT.md)

(back to top)

License

MIT