Varriount/nimskull

Nimskull

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

Code of Conduct · Code of Ethics · Documentation

This repository contains the Nimskull compiler, stdlib, tools, and documentation.

About the Project

Nimskull (temporary name) is a statically typed structured programming
language to create software (itself included) 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.

The project was started as a fork of Nim as it provides a bootstrapped
compiler as a starting point. The overall language will be evolved into something
entirely different and incompatible.

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 refer to the milestones.
The current ones are used as a way to track progress on a topic, rather than
for representing fixed milestones. The old, out-of-date thread about roadmap
progress can be found here.

The current and key areas of development are as follows:

1. decouple the data types used by the different compilation stages
2. simplify the code generators - perform much of the transformation and lowering
   via passes over the mid-end IR (Project)
3. improve tests - core specification as tests (see slim the core below).
   Reorganize existing tests. (Project)
4. nkError/tyError/skerror - replace localError etc approach with an AST
   (nkError) one (Project)
5. comments - incrementally document compiler source for easier learning
6. 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.
• moving decision making out of the code generators will make behaviour of the
  backends consistent with each other
• 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 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:

• 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)
• Windows (Windows XP or later) - x86 and x86_64

Other platforms may work but aren't regularly tested.

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

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

(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.

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 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 an extension sandbox.

Practitioner collaborating and combining their software is assisted 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 incompatible 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 cement 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

(back to top)

License

MIT