J*: A Lightweight Embeddable Scripting Language

J* is a dynamic embeddable scripting language designed to be as easy as possible to embed into another program. It arises from the need of having a modern scripting language with built-in support for OOP whilst mantaning simplicity of use and a low memory footprint. It can be viewed as a middle ground between Python, a more complete scripting language with lots of features and libraries, and Lua, a small and compact language that is simple to embed but doesn't provide OOP functionalities out of the box.
J* tries to take the best of both worlds, implementing a fully featured class system while maintaining a small footprint and employing the use of a stack based API for communication among the language and host program, rendering embedding simple.

J* is:

• Small. The implementation spans only a handful of files and the memory footprint is low thanks to a minimal standard library that provides only essential functionalities
• Easy to use. The API is contained in a single header file and employs a stack based approach similar to the one of Lua, freeing the user from the burden of keeping track of memory owned by the language
• Fully object oriented. Every entity, from numbers to class instances, is an object in J*
• Modular. A fully fledged module system makes it easy to split your code across multiple files
• Easily extensible. The language can be easily extended by creating C functions callable from J* using the API, or by importing C extensions provided as dynamic libraries.

To get a feel of the language, try it in your browser!

The jstar command line interface

Besides the language implementation, a simple command line interface called jstar is provided to start using the language without embedding it into another program.
If the jstar binary is executed without arguments it behaves like your usual read-eval-print loop, accepting a line at a time and executing it:

J*>> var helloWorld = 'Hello, World!'
J*>> print(helloWorld)
Hello, World!
J*>> _

You can even write multiline code, it will look like this:

J*>> for var i = 0; i < 3; i += 1
....     print('Hello, World!')
.... end
Hello, World!
Hello, World!
Hello, World!
J*>> _

When you eventually get bored, simply press Ctrl+d or Ctrl+c to exit the interpreter.

If you instead want to execute code written in some file, you can pass it as an argument to jstar. All arguments after the first will be passed to the language as script arguments, you can then read them from the script this way:

if #argv > 0
    print("First argument: ", argv[0])
else
    raise Exception("No args provided")
end

The jstar executable can also accept various options that modify the behaviour of the command line app. To see all of them alongside a description, simply pass the -h option to the executable.

In addition to being a useful tool to directly use the programming language, the command line interface is also a good starting point to learn how J* can be embedded in a program, as it uses the API to implement all of its functionalities. You can find the code in apps/jstar/.

The jstarc compiler

Another application, called jstarc, is provided alongside the cli and the language runtime. As the name implies, this is a compiler that takes in J* source files, compiles them to bytecode and stores them on file.

Below is a typical usage of jstarc:

jstarc src/file.jsr -o file.jsc

You can even pass in a directory if you want to compile all jsr files contained in it:

# This compiles all *.jsr files in `dir` and stores them in a directory `out`
# Both directories have to exist

jstarc dir/ -o out/

The output .jsc files behave in the same way as normal .jsr source files. You can pass them to the jstar cli app to execute them and can be even imported by other J* files.

Compiled files are not faster to execute than normal source files, as the J* vm will always compile source to bytecote before execution, but have nonetheless some nice advantages:

• Compactness. compiled files are more compact than source files and generally take up less space
• Faster startup. Reading a compiled file is orders of magnitude faster than parsing and compiling source code, so there's almost no delay between importing and actual execution
• Obfuscation. If you don't want your source to be viewed, compiled files are a nice option since all the source and almost all debug information are stripped
• Platform indipendence. Compiled files are cross-platform, just like normal source files. This means that they can be compiled once and shared across all systems that have a J* interpreter.

Linting and IDE support

Check out the Pulsar static analyzer for code linting and static analysis from the command line.
Check the VSCode J* extension for linting and syntax highlighting support in VSCode.

Special thanks

Special thanks to Bob Nystrom and the invaluable crafting interpreters book, on which the VM is based.

My gratitude goes to the Lua project as well, for inspiring the stack-based C API and its amazing pattern matching library, on which the re module is based on. Also, the closures in Lua and implementation of Lua 5 articles were crucial for some parts of the implementation.

Compilation

The J* library requires a C99 compiler, CMake (>= 3.9) and Python (>= 2.7) to be built, and is known to compile on OSX (Apple clang), Windows (both MSVC and MinGW-w64) and Linux (GCC, clang).

To build the provided command line interface jstar, a C++11 compiler is required as one of its dependencies, is written in C++.

You can clone the latest J* sources using git:

git clone --recurse-submodules https://github.com/bamless/jstar.git

After cloning, use CMake to generate build files for your build system of choice and build the all target to generate the language dynamic/static libraries and the command line interface. On UNIX-like systems this can be simply achieved by issuing this in the command line:

cd jstar; mkdir build; cd build; cmake ..; make -j

Once the build process is complete, you can install J* by typing:

sudo make install

Various CMake options are available to switch on or off certain functionalities of the interpreter:

Option name	Default	Description
JSTAR_NAN_TAGGING	ON	Use the NaN tagging technique for storing the VM internal type. Decrases the memory footprint of the interpreter and increases speed
JSTAR_COMPUTED_GOTOS	ON	Use computed gotos to implement the VM eval loop. Branch predictor friendly, increases performance. Not all compilers support computed gotos (MSVC for example), so if you're using one of them disable this option
JSTAR_INSTALL	ON	Generate install targets for the chosen build system. Turn this off if including J* from another CMake project
JSTAR_SYS	ON	Include the 'sys' module in the language
JSTAR_IO	ON	Include the 'io' module in the language
JSTAR_MATH	ON	Include the 'math' module in the language
JSTAR_DEBUG	ON	Include the 'debug' module in the language
JSTAR_RE	ON	Include the 're' module in the language
JSTAR_DBG_PRINT_EXEC	OFF	Trace the execution of instructions of the virtual machine
JSTAR_DBG_STRESS_GC	OFF	Stress the garbage collector by calling it on every allocation
JSTAR_DBG_PRINT_GC	OFF	Trace the execution of the garbage collector
JSTAR_INSTRUMENT	OFF	Enable instrumentation timers scattered throughout the code. Running J* will then produce 3 json files importable from chrome://tracing to view a timeline of executed functions. Supported only when using the GCC compiler on POSIX systems

Binaries

Precompiled binaries are provided for Windows and Linux for every major release. You can find them here.