MALDA™ Reference Manual

The AI-First Programming Language - Version 1.0.11

Home / 1. Introduction

1. Introduction

1.1 Overview

MALDA: The AI-First Programming Language is a modern, object-oriented programming language designed for building AI agents and automation workflows. With native support for LLM integration, agent orchestration, and multi-agent systems, MALDA makes it simple to create intelligent, autonomous applications.

The language features a clean, readable syntax, essential control structures, built-in I/O capabilities, and full object-oriented programming support including classes, inheritance, and polymorphism. What sets MALDA apart is its first-class AI capabilities - built-in classes for LLM clients, conversations, agents, and tools that enable developers to build sophisticated AI applications with minimal code.

The page header is the shipping toolchain version (the same number as the CLI). Core language semantics are specified in malda-language-1.0.

How to approach MALDA: if you already program, start with Home → First Look (prompt + schema + validate, no API key). If you are new to programming, learn the core language next: io.print, variables, input, conditionals, loops, and functions. After the core path, branch into Testing and Quality, Data and Databases, and Browser Apps. Both journeys lead into the same AI-first runtime.

What Does MALDA Stand For?

MALDA: Multi Agent Language with Development Automation - The name MALDA reflects the core principles and design philosophy of the language:

The unified runtime that makes this possible is described next.

1.2 AI Unified Runtime Architecture

MALDA is built on the foundation of AI Unified Runtime Architecture - a unified system where the programming language runtime, AI capabilities, agent framework, tool ecosystem, and deployment are integrated into a single, cohesive architecture. Unlike traditional approaches that combine separate libraries and frameworks, MALDA provides a unified runtime where everything works together seamlessly.

What is AI Unified Runtime Architecture?

AI Unified Runtime Architecture means that AI capabilities are not added as external libraries or frameworks, but are built directly into the language runtime itself. This creates a unified system where:

Traditional Approach vs. Unified Runtime

In traditional approaches, building AI applications requires combining multiple separate components:

This creates overhead from library calls, serialization between components, and complex setup requirements.

With AI Unified Runtime Architecture, all these components are integrated into a single runtime:

Core Components

Unified Language Runtime

The language interpreter includes AI capabilities as first-class features. Classes like LLMClient, Agent, and Conversation are built into the language, not imported from external libraries.

Integrated AI Runtime Layer

AI operations execute within the same runtime as regular code operations. This provides:

Unified Agent Orchestration Runtime

Multiple agents run in the same process and can:

Unified Tool Ecosystem Runtime

Tools are integrated into the runtime:

Unified Deployment Runtime

The compiler embeds the MALDA runtime and AI capabilities into standalone executables:

Benefits

How MALDA Implements It

MALDA's implementation of AI Unified Runtime Architecture consists of four layers:

This architecture makes MALDA truly "AI-first" - not a language with AI features added, but a language where AI is fundamental to the runtime architecture itself.

1.3 Language Features

Core Language Capabilities

MALDA includes:

Core Language Features

AI-First Core Features

⚠️ Important: Autonomous agent systems with tool access pose significant security and operational risks. See 18. Agent Orchestration for a detailed disclaimer and risk mitigation strategies before deploying agents in production.

Web & API Features

1.4 Development Environments

WPF Desktop IDE

1.5 Compiler

The MALDA compiler supports dual-mode compilation:

Both modes produce standalone .exe files with the MALDA runtime embedded. Some external dependencies (e.g., SQL Server/PostgreSQL client libraries, LLamaSharp native DLLs) may require additional DLLs alongside the executable.

1.6 Source Composition: include, using, import, export

MALDA has three ways to bring code in from elsewhere, and one way to control what a file offers to others. All four are top-level only.

FormWhat it does
include "path/file.malda";Composes source: loads and parses another MALDA file into the current program, as if its text were part of it.
using PackageName;Loads an installed package module and merges its exported symbols into the current scope.
import "path/file.malda";Loads a local file as a module and merges only its exported symbols.
import { a, b } from "path/file.malda";Same load, but merges only the named exports into the current scope.
import alias = ...;Same, but binds the exported symbols to a single namespace object instead of the current scope.
export function/class/var/type/schemaMarks a declaration as part of this file's public surface.

When to use each

export and the default surface

export can prefix a function, a class, a var, a type, or a schema declaration:

// math_utils.malda
export function add(a, b) {
    return a + b;
}

export var VERSION = "1.0";
export type Result = Ok(value) | Err(msg);
export schema Contact { name: string; }

function internalHelper(x) {   // not exported
    return x * 2;
}
Important default: the export list is only enforced when a file contains at least one export. A module with no export at all publishes every top-level symbol (including type / schema). Adding your first export to an existing file therefore hides everything you did not mark — use export type / export schema when the module already exports values.

Importing into the current scope or behind a namespace

Without an alias, exported symbols are merged into the current scope. A name that already exists is not overwritten, so the importing file always wins on collisions:

import "shared/math_utils.malda";

print(add(2, 3));      // 5
print(VERSION);        // "1.0"
// internalHelper(2);  // not available: never exported

Selective import pulls a subset of that surface (missing or non-exported names are errors). Offline goldens: Examples/Modules/selective_import.malda, Examples/Modules/export_type_schema.malda — see also docs/selective-imports.md.

import { add, VERSION } from "shared/math_utils.malda";

print(add(2, 3));
print(VERSION);
// unused();           // not imported, even if exported by the module

import { Result, Contact } from "types_lib.malda";
var r = Ok(42);                 // constructors arrive with export type Result
var ok = validate("Contact", dict { "name": "Ada" });

With an alias, the same symbols are grouped into one object, which avoids collisions entirely:

import mathUtils = "shared/math_utils.malda";

print(mathUtils.add(2, 3));   // 5
print(mathUtils.VERSION);     // "1.0"

The same two forms apply to packages, with a dotted package name in place of the string path:

import App.Core;
import UI = App.Web.Components;

Package names beginning with System, Microsoft, or Windows are resolved as .NET namespaces through the interop layer rather than the package manager. See 30. .NET Interop.

Failing to resolve a target is a runtime error: Package or module not found: Name for packages, and the underlying file-not-found message for file imports.

Path and safety behavior for include

In Desktop IDE, virtual tabs do not replace include: they are an editor view over one physical file. They are created only when the source contains explicit // @malda-section Name separators. Include resolution remains file-based and works the same as before.

// Local file composition: everything from these files becomes part of this program
include "shared/math_utils.malda";
include "features/orders.malda";

// Package import into the current scope
using App.Core;

// Package import behind a namespace object
using UI = App.Web.Components;

1.7 Quick Example

Characteristic constructs first (same program as Examples/Basics/first_look.malda). -> Review binds the prompt to the schema. Without await, the call is a rendered template — no API key. validate("Review", …) is the same check await would run on the model JSON.

schema Review {
    summary: string;
    issues: string[];
}

prompt codeReview(code, language) -> Review {
    system: "You are an expert reviewer of {language}.",
    user: "Review this {language} code:\n\n{code}"
}

var rendered = codeReview("function add(a, b) { return a + b; }", "javascript");
io.print(rendered.user);

var checked = validate("Review", {
    "summary": "Looks fine",
    "issues": []
});
if (checked.ok) {
    io.print("schema ok: " + checked.data.summary);
}

Core syntax uses the same statements. Prefer namespaced calls (io.print); flat print still runs. File, path, and environment I/O: 12. Input/Output.

io.print("Hello, World!");

var name = "Alice";
var age = 25;
var pi = 3.14159;
var isActive = true;

var numbers = [1, 2, 3, 4, 5];
numbers.append(6);

function greet(name) {
    return "Hello, " + name + "!";
}

io.print(greet("Bob"));

class Person {
    public var name;
    public var age;
    
    function Person(name, age) {
        this.name = name;
        this.age = age;
    }
    
    public function introduce() {
        io.print($"Hi, I'm {this.name} and I'm {this.age} years old.");
    }
}

var person = new Person("Charlie", 30);
person.introduce();

See Also

← Home Next: 2. Tools & Tooling→