Switch branches/tags
Clone or download
Pull request Compare This branch is 9 commits behind google:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.ci
src
tests
.gitignore
.travis.yml
CONTRIBUTING.md
Cargo.toml
LICENSE
README.md
build.rs
rustfmt.toml

README.md

Starlark in Rust

An implementation in Rust of the Starlark language

Build Status

Disclaimer: This is not an officially supported Google product. This project is supported on a best-effort basis and welcome contributions.

Starlark, formerly codenamed Skylark, is a non-Turing complete language based on Python that was made for the Bazel build system to define compilation plugin.

Starlark has at least 3 implementations: a Java one for Bazel, a go one and this one.

This interpreter was made using the specification from the go version and the Python 3 documentation when things were unclear.

This interpreter does not support most of the go extensions (e.g. bitwise operator or floating point). It does not include the set() type either (the Java implementation use a custom type, depset, instead). It uses signed 64-bit integer.

Usage

You can depend on this crate starlark, it is documented using docs.rs.

A command line interpreter is also provided by this project, it can interpret files passed at the command line and also start a REPL (Read-Eval-Print Loop). The usage of this program is:

$ starlark --help
[Starlark in Rust interpretor]

Usage: ./target/release/starlark [options] [file1..filen]


Options:
    -b, --build_file    Parse the build file format instead of full Starlark.
    -h, --help          Show the usage of this program.
    -r, --repl          Run a REPL after files have been parsed.

Development

Build

This project build with Cargo. Simply run cargo test to test it, cargo build --release to build a release version and cargo run to run the command-line interpreter.

Possible improvements and optimizations

  • Errors:
    • When an identifier is not found, we can suggest close identifier / keyword.
    • Fix suggestions maybe?
    • Better error spans.
    • Recoverable errors (don't stop at the first error, continue parsing).
  • Evaluation:
    • Static rewrite of the AST before evaluation (e.g. for constant values)
  • Awesome feature:
    • Implement a debugging protocol server side (compatible with the Java one, see (bazelbuild/vscode-bazel#6)).