fspl/arf
fspl/arf
Archived
1
1
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity

Update 'Guidelines'

Sasha Koshka 2022-08-30 05:55:45 +00:00
parent abc042a053
commit 9a65bcb2c8
1 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Guidelines.md Normal file

@ -0,0 +1,24 @@
# 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.