The Nim-Works compiler, stdlib, tools, and documentation repository. Nim-Works is presently a derivative of Nim. Its intention best described by:
Nimskull is not an alternative implementation; it's a reimaging of the language that aims for a community where if one uses the language then they also contribute directly to the language. This is a community effort with a strong emphasis on sustainability, the contributor community comes first.
As to why this fork exists, it's a matter of taste and this would not exist if governance, language design, type system, implementation choices, standard library, package management, and more had an acceptable trajectory.
Ultimately this will mean a different community, language, standard library, and much more. For now it's closer to an alternative with most deviations appearing in the standard library, mostly in the form of deleting much of it.
PS. the name Nimskull is temporary
See the FAQ.
The current and key areas of development are as follows:
- improve tests - clarify the language specification and memorialize it in tests. Reorganize existsing tests. Project to track progress.
- nkError - replace
localErroretc approach with an AST (nkError) one - comments - incrementally document compiler source for easier learning
Show more
There are more, the above have been carefully chosen based on the direction of the language; moreover, their impact is far beyond as described and the intention is 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
Currently, this repository is our primary community hub; however, we'll introduce something more interactive 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!
The compiler currently aims to support the following platform and architecture combinations:
- Windows (Windows XP or greater) - 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
gcc3.x/later or an alternative such asclang,Visual C++orIntel C++. It is recommended to usegcc3.x or later. - Either
gitorwgetto download the needed source repositories. - The
build-essentialpackage when usinggccon 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:
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.
First, get the compiler from github:
git clone https://github.com/nim-works/nimskull.git
cd nimskull
Next, run the appropriate build shell script for your platform:
build_all.sh(Linux, Mac)build_all.bat(Windows)
Finally, once you have finished the build steps (on Windows, Mac, or Linux) you
should add the bin directory to your PATH.
NB: This has not been updated from the original Nim section. See the FAQ
Before you start contributing, you should familiarize yourself with the following repository structure:
Show structure
bin/,build/- these directories are empty, but are used when Nim is >built.compiler/- the compiler source code. Also includes nimfix, and plugins withincompiler/nimfixandcompiler/pluginsrespectively.nimsuggest- the nimsuggest tool.config/- the configuration for the compiler and documentation generator.doc/- the documentation files in reStructuredText format.lib/- the standard library, including:
pure/- modules in the standard library written in pure Nim.impure/- modules in the standard library written in pure Nim with dependencies written in other languages.wrappers/- modules that wrap dependencies written in other languages.tests/- contains categorized tests for the compiler and standard library.tools/- the tools includingkoch,niminstandnimweb(mostly invoked viakoch).tools/koch/koch.nim- the tool used to bootstrap Nim, generate C sources, build the website, and generate the documentation.koch.py- the script to bootstrap and launchkoch.nim.Ideally, you should make sure that all tests pass before submitting a pull request. However, if you are short on time, you can just run the tests specific to your changes by only running the corresponding categories of tests. Travis CI verifies that all tests pass before allowing the pull request to be accepted, so only running specific tests should be harmless. Integration tests should go in
tests/untestable.
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 langauge 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.
Show
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.
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 async).
For more information on the koch build tool please see the documentation
within the doc/koch.rst file.
What's the rational for this fork?
We love the original vision behind nim-lang; we believe that an element of the vision was lost. We simply believe a different development process was needed to that which was being used and decided that the best way to see this vision materialize was to enforce that process ourselves.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.Will this break my Nim code?
Maybe. Many experienced users will know that a lot of current code 'works' because of various hacks, or create hacks themselves to make code work. See #8 and the direction for more on this.Will you plan to merge Nim upstream changes?
Generally? No. There will likely be exceptions to this. Our current focus remains on solidifying the foundations before moving forward.Can I help somehow?
Presently we're very interested in people contributing than to growing our community; so if you would like to contribute, a good start is to help the "language spec as tests" effort which is being led by @haxscramper. If you're willing to drive deeper into the compiler then see the "nkError refactor to make the compiler approachable" project.Any chat room on matrix/irc/discord?
Not presently, however this will likely change sometime soon/laterSo the aim isn't just for a different compiler, but a new language?
For the moment, we are aiming for a more well-defined spec through excessive testing which might lead to slight language changes to make it more correct.MIT