Exo is an extensible programming language that makes extensive use of micro-packages.
Exo is an extensible programming language with no base syntax. It defers the implementation of any syntax construct to user code.
The purpose of this mechanism is to be able to manage the features of the language without having to wait for a new language version to be released, nor requiring deep knowledge of the compiler source code. A curated set of standard features is defined and carefully designed as to include only syntax constructs that have been proven to be practical, and a new set of standard features is created whenever one of them is considered obsolete or decidedly harmful. If needed, it is still possible to define custom languages with a feature set branching out of (or even integrally differing from) the accepted standard.
The ast visitor can in theory implement a compiler/interpreter for any existing language, although to this day only a very simple dynamically-typed immutable expression based language has been implemented as a starting point for the standard.
An important concept for Exo is the micro-package. Micro-packages are very small, atomic units of code that can, if needed, require a set of statically typed dependencies to be fulfilled.
In the special case of Exo, a micro-package contains a single value expression. A dependency of some micro-package a can be fulfilled by another micro-package b, as long as the type of the value expression the package b contains satisfies the type of the dependency required by a.
Micro-packages propose an elegant way to resolve ambiguous situations proper to typical package manager solutions, e.g. a package graph containing multiple versions of the same package. They do so by deferring the responsibility to fill in the dependency implementations later on, e.g. when the version of said package is actually safely determinable.
Micro-packages have the following advantages:
- the same package needs not be embedded more than once in a build target, promising to keep release builds as small as possible over the lifetime of a project
- any part of an application is replaceable/mockable, effortlessly making any project scalable and testable
- once a certain implementation exists in the package manager, it theoretically needs not be implemented ever again
- storing datatypes as micro-packages makes implementing new datatype conversions accessible, opening the door to existing code for new purposes
- c++ >= 20
- cmake >= 3.18
So far all subprojects merely depend on header-only libraries.
- runtime linker (ldd on unix platforms)
docker pull exolang/exo[:semver]docker run --rm -it -v $(pwd):$(pwd) -w $(pwd) exolang/exo [cli-args]mkdir build && cd build
cmake ..
make [clean] [subproject]<build project>
make install [subproject]- unified toolchain and one liners https://github.com/exo-language/exo/issues/3
- move from text-based to binary-based ast #2
- simple expression-based language as a standard language starting point
- parser
- compile to llvm byte code
- basic Exo micro-package manager cli (offline)
- online (decentralized?) Exo micro-package manager #1
This project is licensed under the MIT License - see LICENSE.md for details.