# Modules: sharing work between source files

[Concepts explained](README.md)

A **module** is a source file that supplies reusable parts to other files. Imagine a toolbox with separate drawers for drawing helpers and quiz questions. Each drawer has a clear job.

In Pliro, modules are `.pliro` files inside the same portable `.bipli` project. A standalone source file cannot import project modules.

## Import and namespace

Suppose a project contains `helpers.pliro`, with a function named `double`. Another source can use this fragment:

```text
use helpers
say helpers.double(4)
```

This is a project fragment, not a complete standalone program. **Importing** makes a module available. The **namespace** `helpers` lets you say which module owns `double`. It helps keep names organized.

An **export** is something other modules may use. Pliro currently exports top-level variable and function declarations. The [module reference](../syntax/use.md) gives a complete two-file example and the exact rules.

## Dependencies

If one module needs another, the second is a **dependency** of the first. Dependencies initialize before the module that needs them. A circle of imports is an **import cycle**; Pliro rejects it.

Project modules are local files. Importing one does not download an internet package. A missing module means you should check your project, spelling, and path.

Try planning three files for a quiz: the starting program, question data, and scoring helpers. Give each one a small job.

[Project manifests](manifests.md) · [File paths](file-paths.md)