Module FunctoriaSource
The Functoria DSL
Functoria is a DSL to describe a set of modules and functors, their types and how to apply them in order to produce a complete application.
The main use case is mirage. See the Mirage documentation for details.
Functoria is a DSL to write configuration files for functor-heavy applications. Such configuration files (imaginatively called config.ml) usually contains three parts: one for defining toplevel modules, one for defining configuration kyes and one for defining applications using these modules and keys.
Defining toplevel modules
To define toplevel modules, use the main function. Among its various arguments, it takes the module name and its signature. The type is assembled with the Type combinators, like the @-> operator, which represents a functor arrow.
let main = main "Unikernel.Main" (m @-> job)
This declares that the functor Unikernel.Main takes a module of type m and returns a module of type DSL.job. job has a specific meaning for functoria: it is a module which defines at least a function start, which should have one argument per functor argument and should return unit.
It is up to the user to ensure that the declaration matches the implementation, or be rewarded by a compiler error later on. If the declaration is correct, everything that follows will be.
Defining configuration keys
A configuration key is composed of:
- name : The name of the value in the program.
- description : How it should be displayed/serialized.
- stage : Is the key available only at runtime, at configure time or both?
- documentation : It is not optional so you should really write it.
Consider a multilingual application: we want to pass the default language as a parameter. We will use a simple string, so we can use the predefined description Key.Arg.string. We want to be able to define it both at configure and run time, so we use the stage Both. This gives us the following code:
let lang_key =
let doc =
Key.Arg.info ~doc:"The default language for the application."
[ "l"; "lang" ]
in
Key.create "language" @@ Key.Arg.(opt ~stage:`Both string "en" doc)
Here, we defined both a long option "--lang" and a short one "-l" (the format is similar to the one used by Cmdliner. In the application code, the value is retrieved with Key_gen.language ().
The option is also documented in the "--help" option for both the configure subcommand (at configure time) and ./app.exe (at startup time).
-l VAL, --lang=VAL (absent=en) The default language for the application.
Defining applications
To register a new application, use register:
let () = register "app" [ main $ impl ]
This function (which should only be called once) takes as argument the name of the application and a list of jobs. The jobs are defined using the Impl DSL; for instance the operator $ is used to apply the functor main (aka Unikernel.Main) to the default console.
Once an application is registered, it can be configured and built using command-line arguments.
Configuration keys we can use be used to switch implementation at configure time. This is done by using the Key DSL, for instance to check whether lang_key is instanciated with a given string:
let lang_is "s" = Key.(pure (( = ) s) $ value lang_key)
Then by using the if_impl combinator to choose between two implementations depending on the value of the key:
let impl = if_impl (is "fi") finnish_impl not_finnish_implementation
The Functoria DSL allows users to describe how to create portable and flexible applications. It allows to pass application parameters easily using command-line arguments either at configure-time or at runtime.
include DSL
Combinators
The type for values representing module types.
type t is a value representing the module type t.
Construct a functor type from a type and an existing functor type. This corresponds to prepending a parameter to the list of functor parameters. For example:
kv_ro @-> ip @-> kv_ro
This describes a functor type that accepts two arguments -- a kv_ro and an ip device -- and returns a kv_ro.
The type for values representing module implementations.
m $ a applies the functor m to the module a.
Same as impl but with hidden type.
dep t is the (build-time) dependency towards t.
Keys
The type for configure-time command-line arguments.
The type for runtime command-line arguments.
runtime_arg ~pos ?packages v is the runtime argument pointing to the value v. pos is expected to be __POS__. packages specifies in which opam package the value v is defined.
The type for abstract keys.
Sourcetype context = Context.t The type for keys' parsing context. See Key.context.
The type for values parsed from the command-line. See Key.value.
key k is an untyped representation of k.
if_impl v impl1 impl2 is impl1 if v is resolved to true and impl2 otherwise.
match_impl v cases ~default chooses the implementation amongst cases by matching the v's value. default is chosen if no value matches.
Package dependencies
For specifying opam package dependencies, the type package is used. It consists of the opam package name, the ocamlfind names, and optional lower and upper bounds. The version constraints are merged with other modules.
The type for opam packages.
Installation scope of a package.
Sourceval package :
?scope:scope ->
?build:bool ->
?sublibs:string list ->
?libs:string list ->
?min:string ->
?max:string ->
?pin:string ->
?pin_version:string ->
string ->
package package ~scope ~build ~sublibs ~libs ~min ~max ~pin opam is a package. Build indicates a build-time dependency only, defaults to false. The library name is by default the same as opam, you can specify ~sublibs to add additional sublibraries (e.g. ~sublibs:["mirage"] "foo" will result in the library names ["foo"; "foo.mirage"]. In case the library name is disjoint (or empty), use ~libs. Specifying both ~libs and ~sublibs leads to an invalid argument. Version constraints are given as min (inclusive) and max (exclusive). If pin is provided, a pin-depends is generated, pin_version is "dev" by default. ~scope specifies the installation location of the package.
Application Builder
Values of type impl are tied to concrete module implementation with the device and main construct. Module implementations of type job can then be registered into an application builder. The builder is in charge if parsing the command-line arguments and of generating code for the final application. See Functoria.Lib for details.
The type for build information.
Sourceval main :
?pos:(string * int * int * int) ->
?packages:package list ->
?packages_v:package list value ->
?local_libs:string list ->
?runtime_args:Runtime_arg.t list ->
?deps:abstract_impl list ->
string ->
'a typ ->
'a impl main name typ is the functor name, having the module type typ. The connect code will call <name>.start.
- If
packages or packages_v is set, then the given packages are installed before compiling the current application.
Devices
of_device t is the implementation device t.
impl ~packages ~packages_v ~install ~install_v ~keys ~runtime_args ~extra_deps ~connect ~dune ~configure ~files module_name module_type is an implementation of the device constructed by the arguments. packages and packages_v are the dependencies (where packages_v is inside Key.value). install and install_v are the install instructions (used in the generated opam file), keys are the configuration-time keys, runtime_args the arguments at runtime, extra_deps are a list of extra dependencies (other implementations), connect is the code emitted for initializing the device, dune are dune stanzas added to the build rule, configure are commands executed at the configuration phase, files are files to be added to the list of generated files, module_name is the name of the device module, and module_type is the type of the module.
Jobs
Representation of opam packages.
Information about the final application.
Signature for functoria devices. A device is a module implementation which contains a runtime state which can be set either at configuration time (by the application builder) or at runtime, using command-line arguments.
Useful module implementations
job is the signature for user's application main module.
noop is an implementation of job that holds no state, does nothing and has no dependency.
The type for command-line arguments, similar to the usual Sys.argv.
argv is a value representing argv module types.
sys_argv is a device providing command-line arguments by using Sys.argv.
runtime_args a is an implementation of job that holds the parsed command-line arguments. By default runtime_package is "mirage-runtime.functoria" and runtime_modname is "Functoria_runtime".
Representation of module signatures.
Configuration command-line arguments.
Define runtime command-line arguments.
Application builder. API for building libraries to link with config.ml
Creation of CLI tools to assemble functors.
The Functoria DSL allows users to describe how to create portable and flexible applications. It allows to pass application parameters easily using command-line arguments either at configure-time or at runtime.
Wrapper around Bos which provides a "dry run" feature.