In support of comfortable stream-centric (and functional) programming
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
agussusahnti ff5a413bf0 Update '.drone.yml' 3 months ago
.mvn init: SDF3/Statix project as initialized by Spoofax 2 years ago
bin Extraction from streams (#25) 2 years ago
docs docs: Get mkdocs working 2 years ago
editor Add OCaml code generation (#24) 2 years ago
signature Add literal string constants (#19) 2 years ago
src/main/strategies/fostr/strategies init: SDF3/Statix project as initialized by Spoofax 2 years ago
statics Add literal string constants (#19) 2 years ago
syntax Extraction from streams (#25) 2 years ago
tests Extraction from streams (#25) 2 years ago
trans Extraction from streams (#25) 2 years ago
.drone.yml Update '.drone.yml' 3 months ago
.gitignore Add OCaml code generation (#24) 2 years ago
LICENSE chore: Switch to this repository from predecessor 2 years ago
README.md Add literal string constants (#19) 2 years ago
metaborg.yaml feat: sequencing of expressions with newline to same indent (#11) 2 years ago
mkdocs.yml Extraction from streams (#25) 2 years ago
pom.xml init: SDF3/Statix project as initialized by Spoofax 2 years ago

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 centrally organized around the concept of "streams" (somewhat in the spirit of streem and/or Orc, or to a lesser extent, Sisal-is). In fact all higher-type entities will be cast in terms of streams, or in slogan form, "++f++unctions and (binary) ++o++perators are ++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.

  • fostr code uses streams (and their specializations to functions and operators) all the time, so they are first-class entities that are easy to create, pass around, compose, etc.

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