77 lines
3.4 KiB
Markdown
77 lines
3.4 KiB
Markdown
<!--
|
|
|
|
Please keep this document correctly word-wrapped at 70 columns and
|
|
with no trailing whitespace or blank lines at the end! Merge requests
|
|
with modifications to this document will be not be accepted until it
|
|
is formatted correctly! ~~abb
|
|
|
|
-->
|
|
|
|
# AlexScript
|
|
|
|
AlexScript (which is a misnomer; the language will soon be renamed
|
|
since it's not actually a scripting language) is a programming
|
|
language designed to have a functional feel and very high-level
|
|
ergonomics while maintaining speed using strictly-controlled,
|
|
deterministic memory management.
|
|
|
|
## Tools
|
|
|
|
This repository contains the following tools:
|
|
- `axc`, the AlexScript compiler. This can be used as a binary with a
|
|
fairly standard compiler CLI, or as a library for use in other
|
|
programs.
|
|
|
|
The following tools do not exist yet, but are planned:
|
|
- `axci`, the interactive AlexScript interpreter.
|
|
- `axcd`, the Language Server Protocol (LSP) server for AlexScript
|
|
code support in editors, supporting definition peeking and lookup,
|
|
renaming variables and modules, etc.
|
|
- `axfmt`, the standard formatter for AlexScript code; all AlexScript
|
|
code used in this repository must be formatted with `axfmt`, and its
|
|
use is recommended for other projects.
|
|
- `axdoc`, the documentation generator.
|
|
- `alexscript-mode`, an Emacs mode for editing AlexScript code,
|
|
supporting syntax highlighting, automatic indentation, some basic
|
|
keybindings for common tasks, Emacs-side LSP integration for
|
|
communicating with `acxd`, and a collection of `yasnippet` snippets
|
|
for inserting common AlexScript constructs.
|
|
- `alexscript-vsc`, Visual Studio Code plugins and tools for editing
|
|
AlexScript code.
|
|
- `alexscript-vim`, tools and configuration files for optimizing Vim
|
|
and Neovim for editing AlexScript code.
|
|
|
|
## Language features
|
|
|
|
The language is mostly influenced by Rust and Haskell: it has strict
|
|
safety requirements and borrow-checked memory management like that of
|
|
Rust, but its syntax and type system are similar to those of Haskell.
|
|
|
|
Some features the language will most likely have:
|
|
- All functions are pure by default; side effects are chained together
|
|
using an `IO` monad.
|
|
- Despite the language's purity, expressions will be strictly
|
|
evaluated to provide more programmer control.
|
|
- Different monads represent different levels of safety, and can be
|
|
converted using functions marked as `UNSAFE`. The intention is that
|
|
code can be audited by manually checking that all the `UNSAFE`
|
|
transformations are sound, and code that contains no `UNSAFE`
|
|
function calls are guaranteed to satisfy varying definitions of
|
|
soundness:
|
|
- The `IO` monad represents computations that might have side
|
|
effects on the real world. If a computation of type `IO` is known
|
|
by the programmer to not have side effects on the real world, then
|
|
it can be converted to a pure computation using the standard
|
|
library function `UNSAFE_assertPure : IO a -> a`.
|
|
- The `MemoryUnsafe` monad represents computations that might read
|
|
from or write to memory that is not allocated correctly: for
|
|
example, `readPtr`, which reads from a raw pointer, is of type
|
|
`MemoryUnsafe a` because the pointer is not known to be valid. If
|
|
a computation has been confirmed to be safe by the programmer, it
|
|
can be converted to an `IO` computation using
|
|
`UNSAFE_assertMemorySafe : MemoryUnsafe a -> IO a`.
|
|
- Further safety monads may be added in the future.
|
|
-
|
|
|
|
## Compilation
|