feat(proposals): introduce evolution proposals

Author: vknabel

proposals/LE-000-template.md

@@ -0,0 +1,33 @@
+# Template Proposal
+
+- Proposal: LE-000
+- Status: **Draft**
+- Author: [**@vknabel**](https://github.com/vknabel)
+
+## Introduction
+
+What is the proposed feature? What problem does it solve?
+
+## Motivation
+
+Why is this change important to you? How would you use it? How can it benefit other users?
+
+## Proposed Solution
+
+Describe the solution you'd like. Provide examples and describe how it works. Define any new terminology.
+
+## Detailed Design
+
+Describe the design of the solution in detail. How will it be implemented?
+
+## Changes to the Standard Library
+
+List any new modules, types, functions, etc. that will be added to the standard library. Highlight any breaking changes.
+
+## Alternatives Considered
+
+Describe alternative approaches to addressing the same problem, and why you chose this approach instead.
+
+## Acknowledgements
+
+List people who have contributed to the design of this proposal. Also mention any prior art, such as how other languages have solved this problem.

proposals/LE-001-sandboxing-and-timeouts.md

@@ -0,0 +1,54 @@
+# Sandboxing and Timeouts
+
+- Proposal: LE-001
+- Status: **Draft**
+- Author: [**@vknabel**](https://github.com/vknabel)
+
+## Introduction
+
+In this proposal we want to discuss the possibility of adding sandboxing and timeouts to the Lithia command line interface. This will be accomplished by implementing a whitelist for external declarations on a module level.
+
+To avoid infinitely running scripts, it should also be possible to set a timeout for the execution of a script.
+
+## Motivation
+
+In security critical or embedded environments, it is important to be able to limit the power of a program.
+The first practical use case for this will be the evaluation of the `Potfile`. It will be executed whenever opening the project and before actually starting the program itself.
+
+The Potfile execution needs to be fast and secure.
+
+## Proposed Solution
+
+The Lithia CLI will get additional configuration options to allow limiting external definitions and setting timeouts.
+
+```bash
+LITHIA_TIMEOUT=1s \
+LITHIA_EXTERNAL_DEFINITIONS=docs,fs,os,rx \
+lithia run [script]
+```
+
+## Detailed Design
+
+`LITHIA_TIMEOUT` will be used to set a timeout for the execution of a script. The default value will be `0s` which means no timeout.
+
+`LITHIA_EXTERNAL_DEFINITIONS` will be used to set a whitelist for external definitions. The default value will be `*` which means all external definitions are allowed. External definitions of `prelude` are always allowed.
+
+The `Potfile` will always be executed with `LITHIA_TIMEOUT=1s` and `LITHIA_EXTERNAL_DEFINITIONS=rx`. No matter what the user has set.
+
+### Merging the Environment Variables
+
+If the user has manually set the environment variables more strict than the default values for the `Potfile` execution, the more strict values will be used.
+
+For example if the user has set `LITHIA_EXTERNAL_DEFINITIONS=docs,os,rx` and the `Potfile` contains `LITHIA_EXTERNAL_DEFINITIONS=docs,fs,os,rx`, the final value will be `docs,os,rx`.
+
+## Changes to the Standard Library
+
+No changes to the standard library are required.
+
+## Alternatives Considered
+
+In the future command line flags or configuration files might be used to set these values.
+
+## Acknowledgements
+
+List people who have contributed to the design of this proposal. Also mention any prior art, such as how other languages have solved this problem.

proposals/LE-002-potfile-scripting.md

@@ -0,0 +1,63 @@
+# Potfile Scripting
+
+- Proposal: LE-002
+- Status: **Draft**
+- Author: [**@vknabel**](https://github.com/vknabel)
+
+## Introduction
+
+This proposal adds some basic subcommands to the `lithia` CLI to allow user defined scripts to be executed.
+
+## Motivation
+
+Every project has specific jobs to be done. These jobs are often repetitive and can be automated. This proposal aims to provide simple access to these scripts.
+
+## Proposed Solution
+
+Within the `Potfile`, new commands that execute a specific Lithia file as a script can be defined using the `pots.cmds.script` function. Additional help context can be provided on the existing command. The command can be executed using `lithia [script]` or `lithia run [script]`.
+
+```lithia
+let testCmd = cmds.script "test", "cmd/test.lithia"
+testCmd.summary "runs all tests"
+testCmd.flag "verbose", "verbose logging"
+testCmd.env "LITHIA_TESTS", "1"
+```
+
+Similar, the `pots.cmds.bin` function can be used to define a command that executes a binary. Under the hood `/usr/bin/env` will be used to lookup the binary. In case of `lithia` itself, the currently executed `lithia` binary will be used.
+
+```lithia
+cmds.bin "example", ["lithia", "test"]
+```
+
+## Detailed Design
+
+The user adds the commands of their choice to their `Potfile`.
+The Lithia interpreter will now execute it and will proceed working on the internal store structure.
+
+The execution of the Potfile takes place in a sandboxed environment which whitelists possible external module imports to avoid direct access to the file system and other resources. It will also be time-restricted to at most one second using Go `context.Context`.
+
+To avoid privilege escalation, scripts declared in the `Potfile` with overridden `LITHIA_TIMEOUT` or `LITHIA_EXTERNAL_DEFINITIONS`, can only restrict the environment further. They cannot allow more access to the environment.
+
+## Changes to the Standard Library
+
+Adds a new module `pot.cmds`:
+
+- _func_ `script alias, path` - returns a `MutableCommand`.
+- _func_ `bin alias, path` - returns a `MutableCommand`.
+- _data_ `MutableCommand` - a mutable command that can be used to configure the command.
+  - _func_ `summary text` - sets the summary text for the command.
+  - _func_ `flag name, description` - adds a flag to the command.
+  - _func_ `env name, value` - adds an environment variable to the command.
+
+Other non-final additions are internal and include:
+
+- _let_ `store` - a stateful application store which stores the commands and in the future more commands.
+
+## Alternatives Considered
+
+- `pot [script]`, `lithia run [script]` or `lithia pot [script]`
+
+## Acknowledgements
+
+`npm run [script]`, `yarn [script]`, `swift run [target]` and
+`archery [script]`.

proposals/LE-003-string-concatenation.md

@@ -0,0 +1,42 @@
+# Template Proposal
+
+- Proposal: LE-003
+- Status: **Draft**
+- Author: [**@vknabel**](https://github.com/vknabel)
+
+## Introduction
+
+Adds the ability to concatenate strings using the `..` operator.
+
+## Motivation
+
+Strings need to be concatnated often. The current way to do this is to use the `strings.concat` function, which feels a bit verbose in many cases.
+
+A simple `..` might improve the readability of the code.
+
+## Proposed Solution
+
+We add a new left-associative operator `..` to the language, which is used to concatenate strings with a low precendence.
+
+## Detailed Design
+
+The `..` operator is left-associative, and has a precedence of 5.
+This allows comparisions of concatenated strings.
+
+```lithia
+"Hello" .. " " .. "World" == "Hello World"
+```
+
+## Changes to the Standard Library
+
+Only implementations are affected.
+`strings.concat` will still be available, and will never be deprecated.
+
+## Alternatives Considered
+
+We could overload `+`. But due to the dynamic typing it may be confusing in practice.
+`++` is also used in different languages, but we do not want to mix up the meaning of `+` and `++`.
+
+## Acknowledgements
+
+Mimics the `..` operator in Lua.

proposals/LE-004-new-concurrency-model.md

@@ -0,0 +1,69 @@
+# New Concurrency Model
+
+- Proposal: LE-004
+- Status: **Draft**
+- Author: [**@vknabel**](https://github.com/vknabel)
+
+## Introduction
+
+The initially planned concurrency model for Lithia was based on Functional Reactive Programming. In practice this turned out to not fit the language very well. FRP is complex, yet Lithia tries to be simple. This proposal describes a new concurrency model, which is inspired by Go's channels and coroutines.
+
+## Motivation
+
+Lithia has a strong and dynamic type system. The current approach of FRP wraps all values and therefore forcing users to unwrap them. This forces developers to double check the docs for the return type. Otherwise this leads to avoidable runtime errors.
+
+When comparing this with the Go concurrency model, where async function calls are blocking, but still return the same value as normal function calls. This should lead to a better developer experience in Lithia programs.
+
+## Proposed Solution
+
+The new concurrency model is based on channels and coroutines. Coroutines are similar to async functions, but they are not blocking. They can be called using the `async` function. The `async` function is followed by an expression, which is executed in a new coroutine. The coroutine can be suspended using the `await` function. The `await` keyword is followed by an expression, which is evaluated in the current coroutine. The result of the expression is returned to the coroutine, which called `await`.
+
+```lithia
+let task = async { =>
+    let channel = Channel 0
+    select { on, closed =>
+        on channel, { value =>
+            print value
+        }
+        on None, { _ =>
+            print "No value"
+        }
+        closed channel, { reason =>
+            print reason
+        }
+    }
+}
+await task
+```
+
+## Detailed Design
+
+`Channel` is just a wrapper around a Go-channel. But in contrast to `close` in Go, `close` in Lithia takes a reason.
+
+The `async` function directly creates a new Goroutine with a `Task` under the hood. It is implemented similar to `rx.Future`.
+
+## Changes to the Standard Library
+
+The `rx` module will be removed including the types `rx.Async`.
+`rx.Variable` will be moved to `prelude.Variable`. `rx.Future` will be moved to `prelude.Future`.
+
+In module `prelude`:
+
+- _extern_ `Channel`
+  - can be called as `Channel bufferSize`
+  - _func_ `send value`
+  - _func_ `close reason`
+- _func_ `select func`
+- _extern_ `async expr`
+- _func_ `await future`
+- _extern_ `Variable` defined as before
+- _extern_ `Task` defined as `rx.Future` before, but with all references to `results.Result` removed. They can't fail anymore.
+
+## Alternatives Considered
+
+Most alternatives are more complex and might impact developer experience.
+The `Task` could be dropped, but it might be useful.
+
+## Acknowledgements
+
+This is heavily inspired by Go. `Task` is inspired by Swift.

proposals/README.md

@@ -0,0 +1,12 @@
+# Lithia Evolution Proposals
+
+The development of Lithia is now driven by evolution proposals. New proposals can be created by anyone. As a starting point, you can [copy the template](./LE-000-template.md).
+
+## Proposals
+
+| Proposal                                      | Status | Title                   |
+| --------------------------------------------- | ------ | ----------------------- |
+| [LE-001](./LE-001-sandboxing-and-timeouts.md) | Draft  | Sandboxing and Timeouts |
+| [LE-002](./LE-002-potfile-scripting.md)       | Draft  | Potfile Scripting       |
+| [LE-003](./LE-003-string-concatenation.md)    | Draft  | String Concatenation    |
+| [LE-004](./LE-004-new-concurrency-model.md)   | Draft  | New Concurreny Model    |