forked from glen/fostr
Glen Whitney
804a00902a
Caveat: type is still not being assigned for the Sequence() constructor. Also fixes the parsing of literal strings (whitespace just after the opening quote was being ignored, and was ambiguous just before the opening quote).
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# 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](https://github.com/matz/streem) and/or
|
|
[Orc](http://orc.csres.utexas.edu/index.shtml), or to a lesser extent,
|
|
[Sisal-is](https://github.com/parsifal-47/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.
|
|
|
|
<!-- /md -->
|
|
Like just about every other language, this documentation begins with a
|
|
[whirlwind tour](http::/studioinfinity.org/fostr/basic).
|