Introduction

These are guidelines to follow when designing new language features, working on the compiler, or any other related tooling.

0. Decouple Standard Library

In some languages, certain syntactical or environmental features depend on the presence of a standard library. Even C does to an extent, with the = { 0 } intializer (it calls memset in the background). The ARF standard library will be fully optional, and decoupled from the language. Parts of the standard library should be decoupled from eachother as well. There must be some internal dependencies among them (for example, things like IO and memory management, as well as common interfaces and generics) but it should be as non-monolithic as possible.

1. Keep It Simple

The language itself must be extremely simple. It shouldn't have a lot of concepts, and its syntax should be as clean and regular as possible. The user should not feel like they're always discovering some new feature or quirk with it.

Keep this in your mind:

A designer knows [they have] achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

2. ARF is Immutable

Language features, and for the most part program structure, must be immutable. This means nothing like reflection, or operator overloading.

3. Static over Dynamic

When solving a problem, or implementing a necessary abstraction, prefer a static solution over a dynamic one. This makes a program easier to analyze and reason about.

4. Data is Immutable by Default

Data must be immutable by default. If the user wants to modify a value at some point, they must explicitly delclare the variable to be mutable.

5. Manual Memory Management

We can't have anything like a garbage collector, because that violates guidelines 0 and 9. A borrow checker similar to rust's could be implemented, though.

6. Zero Ambiguity

When looking at any part of ARF syntax, it should be abundantly clear what it means. A good rule of thumb is if its hard for the parser to reason about it, its hard for the user to reason about it too. Syntax should be thematically cohesive, but asymmetrical. Conceptually different things should look different.

7. One line at a Time

You've probably seen some gross java code that flies off the right side of the screen before. We are here to avoid that. The language's syntax should encourage writing code that spreads vertically and not horizontally, with minimal nesting.

8. Compile to Object Files

Each ARF module will compile to it's own object file. This method has its own strengths and weaknesses—and the language should be designed and implemented accordingly.

9. Be Utterly Transparent

Do not generate new functions or complex logic that the user does not explicitly write. The underlying processes behind high level operations should be extremely obvious.