Module System
1. Kernel
The kernel represents the Jazz runtime. The kernel is a thin layer on top of Scheme that implements language agnostic units and packages systems. A Jazz application can be seen as a built kernel + libraries of packages. To build the kernel, launch the build system and type 'make kernel'. This will create a kernel.exe executable in your installation directory. Note that a Jazz kernel statically includes the whole underlying Scheme system so that for instance, a kernel built on top of Gambit has access to every feature and API of Gambit.1.1. Launch Parameters
Every Jazz application supports the following launch parameters:
| Parameter | Description |
|---|---|
| /run | Name of the product to run |
Examples:
1.2. Customization
The HOME/.jazz directory is called the user directory. It contains user wide settings that the kernel will always apply. See the section about profiles for ways to create separate sets of customizations for Jedi.- .jazzini The kernel will load early this Scheme file that can be used to customize many of the kernel's features.
2. Scheme
2.1. R5RS
2.2. SRFI
2.3. Gambit
2.4. Other Scheme Systems
3. Units
3.1. Unit
A Unit is basically a file of Scheme code that was given a name. That name can then be used to load, compile, ... the unit. The kernel will automatically located the unit by searching all packages and ensure that it is loaded only once. Syntax:(unit name (require (unit-name) ...) expr ...)Examples:
(unit fib (define (fib n) (if (or (= n 0) (= n 1)) n (+ (fib (- n 1)) (fib (- n 2)))))) (unit test (require (fib)) ...)
3.2. Module
A module is a unit that implements a specific dialect. A module will walk it's code and resolve all symbols at walk time. Currently supported dialects are:- scheme
- jazz
(module name dialect-name (require (unit-name) ...) (export (unit-name) ...) (import (unit-name) ...) expr ...)Examples:
(module jazz.sample.world jazz (import (jazz.platform) (jazz.system) (jazz.system.process)) (class World extends Process (method (start-process) (system-message "Hello World!") (exit-process))))
3.3. Resource
A resource is a triplet (package path . extension) representing a resource inside a package.3.3.1. Manifest
3.4. Product
A product is the runtime implementation of some user level entity that can be run and built. They correspond to targets in the build system. For instance, when doing 'make jedi', the build system will find the 'jedi' product and ask it to build itself. Products are listed inside their package manifest.4. Packages
4.1. Repository
A repository is where packages are located. A repository is simply a directory that will be scanned for packages. Note that repository order is important as it defines search precedence. The kernel defines three standard repositories:- Build This repository is where the build system will build all units. By default it is the bin directory.
- Jazz The Jazz source repository located in lib. Note that a compiled unit can potentially be found in more than one repository. For instance as a binary compiled unit and as source unit. When loading, the kernel will choose the latest modified. This greatly eases development as you never have to recompile to test a change as the unit system will automatically load the newer source code over the compiled one.
4.2. Package
A package is the deployment unit that groups together related resources like code units. Packages are discovered automatically and their order within their repository should not be relevant. They are similar in function to Ruby gems, Chicken eggs, Gambit snowballs, ... Every package needs a manifest file at the toplevel. This file contains meta information about the package and is named .package.(package jedi (root "src") (products (jedi (unit jedi.product) (dependencies platform))))