Skip to content
/ venice Public

Venice, a Clojure inspired sandboxed Lisp dialect with Java interoperability serving as a safe scripting language.

License

Notifications You must be signed in to change notification settings

jlangch/venice

Repository files navigation

Gitpod Ready-to-Code Java Version CI

Release (latest by date) Release Date GitHub commits since latest release (by date)

Venice

Venice is a Clojure inspired sandboxed Lisp dialect with excellent Java interoperability.

Overview

Venice is a Lisp dialect born from the need for a safe, sandboxed language that is suitable to serve as a scripting and expression language, to implement scriptable extension points and rules for applications, and to drive standalone applications.

Venice supports macros, tail-recursion, dynamic code loading, multimethods, protocols and many more. It comes with excellent Java interoperability, and a configurable sandbox that can prevent all sorts of dangerous JVM interactions like reading/writing files, invoking System.exit(0) or any other malicious action. Venice has been designed from the ground-up with a sandbox making it a first class citizen.

Venice comes with a comprehensive library of 900+ core functions. It's immutable persistent data structures together with Clojure style atoms, futures, promises, and agents greatly simplify writing concurrent code.

Because Venice does not depend on any runtime libraries (other than the JVM) you can easily add it as standalone .jar to your classpath.

Venice requires Java 8 or newer.

Want to try Venice in a REPL? Test it on Gitpod

Cheat Sheet

Cheat Sheet: HTML PDF

Change Log

Change Log

Documentation

Getting the latest release

You can can pull it from the central Maven repositories:

<dependency>
  <groupId>com.github.jlangch</groupId>
  <artifactId>venice</artifactId>
  <version>1.12.24</version>
</dependency>

Contributing

I accept Pull Requests via GitHub. There are some guidelines which will make applying PRs easier for me:

  • No tabs! Please use spaces for indentation.
  • Respect the existing code style for each file.
  • Create minimal diffs - disable on save actions like reformat source code or organize imports. If you feel the source code should be reformatted create a separate PR for this change.
  • Provide JUnit tests for your changes and make sure your changes don't break any existing tests by running gradle.

License

This code is licensed under the Apache License v2.

3rd Party Open Source