How it works

Write

You will write a project as a folder of small, named source files. One command will create a ready-to-build project (command names may change before launch):

ael init support

ael init will create three files at the project's root:

• main.ael, the program's entry point;
• pack.ael, the packages the project uses, empty to begin with;
• metadata.ael, the project's name and settings.

Every other source file will hold one component, and its name will say which: summarize.node.ael will hold the node summarize, and support.agent.ael the agent support. Agents, nodes, edges, configuration and hooks will each get their own file, so a project's structure will read at a glance. Project layout shows a complete project.

When you add a package, it will go into pack.ael, and the lock file pack.lock beside it will record the exact versions your builds use. One manifest and one lock file will give reproducible builds that also work offline.

Check

ael check will check a project, a folder or a single file before anything runs:

• names and file roles, and the size limit of every source file;
• types, including the inputs and outputs of agents and nodes;
• which functions each file may call, and what each piece of code is allowed to do;
• hooks, packages, and whether the chosen target can offer what the program needs.

Type, ownership and permission mistakes will be caught here, not when the program runs. Diagnostics will point at your source, and ael check --json will report them in a machine-readable form for your own scripts. ael fmt will format your source, and ael fmt --check will list the files it would change without changing them.

Build

Building will turn a checked project into a native program for one target: a native executable for an operating system, or a firmware image for a microcontroller board.

ael build --target <target> -o build/support

Every build will start by checking the complete reference map: what references what, beginning at main. Only what your program reaches will go into it, so an HTTP-only app will carry no gRPC or WebSocket code. ael refmap will show the same map for a whole project, a folder or one file, and list unused code and packages.

A feature a target cannot support will fail at compile time, not on the device. ael build --debug will add what standard native debuggers need to debug at source level.

You will also be able to split the step in two: ael compile will produce compiled AEL for every component, and ael build will build a native program from compiled AEL without needing the source.

Run

ael run will check, build and run a project in one step, through the same checks as a build:

ael run

The result will be a self-contained native program, with no interpreter or virtual machine to run and nothing else to install for desktop and server programs. Nothing will download when it starts: your lock file will have pinned every package before the build. A console agent will need no server; you will add the HTTP package and declare routes only when you want it to serve an API.

Each run of an agent will have its own run ID and budget, and its configuration will be locked into a snapshot for that run, so settings cannot change underneath a running agent.

One toolchain

The AEL toolchain will be self-contained: one install will take your code all the way to a native program. Planned targets lists the targets planned for Beta 0.0.1.

Next

• A first program walks through the four steps with a small project.
• Glossary explains the words used here.