A dynamic language and bytecode VM.
Go to file
Calvin Rose 1f37919f39 Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
cmake Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
examples Remove some c functions in favor of bytecode. 2018-07-02 00:12:36 -04:00
natives Enable suspending repl with ctrl-z. 2018-06-24 13:18:44 -04:00
src Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
test Remove some c functions in favor of bytecode. 2018-07-02 00:12:36 -04:00
.gitignore Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
.travis.yml Switch over to Cmake fully. 2018-01-29 15:46:26 -05:00
CMakeLists.txt Reenable cmake build. 2018-07-03 23:19:16 -04:00
LICENSE Update copyright to 2018. Add string methods. 2018-05-17 23:41:20 -04:00
Makefile Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
README.md Rename boot.dst to core.dst 2018-07-04 00:21:18 -04:00
appveyor.yml Remove x86 target in appveyor.yml becuase its not valid 2018-02-01 21:05:23 -08:00

README.md

dst

Build Status Appveyor Status

Dst is a functional and imperative programming language and bytecode interpreter. It is a modern lisp, but lists are replaced by other data structures with better utility and performance (arrays, tables, structs, tuples). The language can also easily bridge to native code written in C, and supports abstract datatypes for interfacing with C. Also support meta programming with macros, and bytecode assembly for the dst abstract machine. The bytecode vm is a register based vm loosely inspired by the LuaJIT bytecode format, but simpler and safer (bytecode can be verified by the assembler).

There is a repl for trying out the language, as well as the ability to run script files. This client program is separate from the core runtime, so dst could be embedded into other programs.

Implemented in mostly standard C99, dst runs on Windows, Linux and macOS. The few features that are not standard C (dynamic library loading, compiler specific optimizations), are fairly straight forward. Dst can be easily ported to new platforms.

There is not much in the way of documentation yet because it is still a "personal project" and I don't want to freeze features prematurely. You can look in the examples directory, the test directory, or the file src/core/core.dst to get a sense of what dst code looks like.

For syntax highlighting, there is some preliminary vim syntax highlighting in dst.vim. Generic lisp syntax highlighting should, however, provide good results.

Features

  • First class closures
  • Garbage collection
  • First class green threads (continuations)
  • Mutable and immutable arrays (array/tuple)
  • Mutable and immutable hashtables (table/struct)
  • Mutable and immutable strings (buffer/string)
  • Lisp Macros
  • Byte code interpreter with an assembly interface, as well as bytecode verification
  • Proper tail calls.
  • Direct interop with C via abstract types and C functions
  • Dynamically load C libraries
  • Functional and imperative standard library
  • Lexical scoping
  • Imperative programming as well as functional
  • REPL
  • Interactive environment with detailed stack traces
  • SQLite bindings

Documentation

API documentation and design documents can be found in the wiki. Not at all complete.

Usage

A repl is launched when the binary is invoked with no arguments. Pass the -h flag to display the usage information. Individual scripts can be run with ./dst myscript.dst

If you are looking to explore, you can print a list of all available macros, functions, and constants by entering the command (all-symbols) into the repl.

$ ./dst
Dst 0.0.0 alpha  Copyright (C) 2017-2018 Calvin Rose
dst:1:> (+ 1 2 3)
6
dst:2:> (print "Hello, World!")
Hello, World!
nil
dst:3:> (os.exit)
$ ./dst -h
usage: ./dst [options] scripts...
Options are:
  -h Show this help
  -v Print the version string
  -s Use raw stdin instead of getline like functionality
  -e Execute a string of dst
  -r Enter the repl after running all scripts
  -p Keep on executing if there is a top level error (persistent)
  -- Stop handling option
$

Compiling and Running

Dst can be built with Make or CMake. Use Make if you are on a posix system and don't like CMake. Use CMake if you are on Windows or like CMake.

Make

cd somewhere/my/projects/dst
make
make test

CMake

On a posix system using make as the target build system, compiling and running is as follows (this is the same as most CMake based projects).

cd somewhere/my/projects/dst
mkdir -p build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
make test

The repl can also be run with the CMake run target.

make run

Examples

See the examples directory for some example dst code.

SQLite bindings

There are some sqlite3 bindings in the directory natives/sqlite3. They serve mostly as a proof of concept external c library. To use, first compile the module with Make.

make natives

Next, enter the repl and create a database and a table.

dst:1:> (import natives.sqlite :as sql)
nil
dst:2:> (def db (sql.open "test.db"))
<sqlite3.connection 0x5561A138C470>
dst:3:> (sql.eval db `CREATE TABLE customers(id INTEGER PRIMARY KEY, name TEXT);`)
@[]
dst:4:> (sql.eval db `INSERT INTO customers VALUES(:id, :name);` {:name "John" :id 12345})
@[]
dst:5:> (sql.eval db `SELECT * FROM customers;`)
@[{"id" 12345 "name" "John"}]

Finally, close the database connection when done with it.

dst:6:> (sql.close db)
nil