In support of comfortable stream-centric (and functional) programming
Go to file
Glen Whitney 527f802793
continuous-integration/drone/push Build is passing Details
docs: Get mkdocs working
2021-01-30 19:48:03 -08:00
.mvn init: SDF3/Statix project as initialized by Spoofax 2021-01-30 12:27:10 -08:00
bin chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
docs docs: Get mkdocs working 2021-01-30 19:48:03 -08:00
editor chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
src/main/strategies/fostr/strategies init: SDF3/Statix project as initialized by Spoofax 2021-01-30 12:27:10 -08:00
syntax chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
tests docs: Get mkdocs working 2021-01-30 19:48:03 -08:00
trans chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
.drone.yml chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
.gitignore chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
LICENSE chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
README.md chore: Switch to this repository from predecessor 2021-01-30 15:37:53 -08:00
metaborg.yaml init: SDF3/Statix project as initialized by Spoofax 2021-01-30 12:27:10 -08:00
mkdocs.yml docs: Get mkdocs working 2021-01-30 19:48:03 -08:00
pom.xml init: SDF3/Statix project as initialized by Spoofax 2021-01-30 12:27:10 -08:00

README.md

The fostr programming language

I don't really like to write code, but I do like the things that coding can build for me: accounting systems for non-profits I care about, spreadsheets that have a reasonable calculation language for cell contents, geometric visualizations that really help to understand three (and maybe even four!) dimensions.

So I embarked on this project to see if I could produce as comfortable a language as possible to work in, given that I inevitably will be doing a bunch of coding. The language will be organized around (unary) ++f++unctions, (binary) ++o++perators, and (nullary) ++str++eams, hence the name "fostr".

Other guiding principles:

  • Maximize signal to noise ratio in code, which means minimizing the number of symbols that have to be there just for the syntax; reducing punctuation; seeking brief syntax that is not too terse; etc.

  • Since code is always structurally indented anyway, make use of that and don't repeat information that's in the whitespace. This principle meshes well with the previous one, and if whitespace significance is baked into the language design from the ground up, it can be kept both effective and natural.

  • Code uses functions all the time. So needless to say, functions should be first-class entities that are exceptionally easy to create, pass around, etc.

  • And true to the name, operators and streams should be just as easy to handle.

  • Try to keep the constructs available as simple to reason about as possible, and practical to use. So side effects are OK, and it should be clear when they occur and in what order. And if possible, fostr will consist only of expressions, no other syntactic constructs. Everything has a value.

Like just about every other language, this documentation begins with a whirlwind tour.