# use — import a project module

[Syntax and values](README.md)

```text
use helpers
use drawing.shapes
```

`use` imports a project-local module. It is valid only at top level in a
portable project. See [Section 12](../../../pliro-syntax.en.md#12-project-local-modules).

Modules are `.pliro` source files inside one `.bipli` project. They are not
external packages and do not perform network resolution.

## Import paths and namespaces

```text
use helpers
use drawing.shapes
```

`helpers` resolves `helpers.pliro`. `drawing.shapes` resolves
`drawing/shapes.pliro`. Resolution is rooted at the project, and the final path
component becomes the [namespace](../concepts/modules.md):

```text
shapes.square(40)
```

Every dotted component is an exact, case-sensitive Pliro identifier and maps to
one directory or file-name component. An English keyword cannot be a `use` path
component because the lexer does not classify it as an identifier.

## Complete two-source example

`helpers.pliro`:

```text
# language: en
let greeting = "Hello from a module"

function twice(value):
    return value * 2
```

`main.pliro`:

```text
# language: en
use helpers

say helpers.greeting
say helpers.twice(4)
```

## Module rules

- `use` must occur at top level.
- A `use` namespace is visible only after its statement.
- Every top-level `let` and `function` declaration is currently exported.
- Imported namespace bindings and direct member assignments are read-only to
  the importer.
- A namespace is not an ordinary runtime value; qualify one of its members.
- Reachable dependencies initialize once, dependency-first, before the entry
  source.
- Import cycles, missing modules, missing members, and ambiguous paths are
  compile-time errors.
- Unreachable project sources are checked but do not execute.
- Standalone `.pliro` files cannot use project modules.

Read-only imports are not deeply frozen collection objects. If an exported
value is a list or map, assigning it to a local name retains normal shared
collection storage; mutating an existing element through that local alias is
visible through the export. A function in the defining module may also update
that module's own top-level variables.

Import aliases, private exports, re-exports, packages, and external dependencies
are not implemented.

## Related entries

[Syntax and values](README.md) · [Built-ins](../builtins/README.md) · [Programming guides](../guides/README.md)