forked from glen/fostr
Glen Whitney
991976d3a8
feat: sequencing of expressions with newline to same indent Also revised README to reflect greater emphasis on streams. Haskell code generation unsurprisingly required a fairly significant rework. Resolves #3. Co-authored-by: Glen Whitney <glen@studioinfinity.org> Reviewed-on: glen/fostr#11 Co-Authored-By: Glen Whitney <glen@nobody@nowhere.net> Co-Committed-By: Glen Whitney <glen@nobody@nowhere.net>
42 lines
2.0 KiB
Markdown
42 lines
2.0 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)). 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).
|