3 Guidelines
Sasha Koshka edited this page 2022-08-24 16:43:43 +00:00

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 about it.

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's flow easier to analyze and reason about. The compiler should not generate new functions or complex logic that the user has not written.

4. 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 guideline 4. 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 flows vertically and not horizontally, with minimal nesting.